9 ms·

It seems Everyone is taking for granted the claim that this is about DRM. The claim is that websites (not Google) will use this signal to allow or deny access

by cowl 3y ago

It seems Everyone is taking for granted the claim that this is about DRM. The claim is that websites (not Google) will use this signal to allow or deny access but this is already possible with various means. Google or any other Browser vendor do not have a say on how websites use or misuse features. > There is a tension between utility for anti-fraud use cases requiring deterministic verdicts and high coverage, and the risk of websites using this functionality to exclude specific attesters or non-attestable browsers. This risk is already present and actually happening. What makes this not widespread is not that it is not possible (it is) but that it is unpopular. Websites that you are forced to use (many banks for example) do it every day and they get away it with it because you have no choice. Many articles are just reapeating the "DRM" claim without explaining how is this different, what does Google have to do with how websites choose to treat their users or what solution they would propose. It seems to me just protest for the sake of it because it's trendy to question every Google Initiative. And yes every Google Initiative must be questioned but I don't see any questioning here beside just parroting in article after article what someone identified as a potential misuse without any critical thought going into it. Might as well autogenerate the contents with AI already because the utility of all articles i have seen on this topic is the same, just rearrange words without adding anything to it.

choeger 3y ago
> what does Google have to do with how websites choose to treat their users or what solution they would propose Google owns YouTube. Is it so hard to imagine that some product manager at YouTube counted the losses due to adblockers and asked a team in Chrome to prevent them?
- cowl 3y ago
  Youtube can and in some measure is already doing it without this new API. If google wanted to be sneaky they can provide whatever data they want to Youtube alone without making it a public standard. you see how all of these fears are contorted reasoning because you want to try to find something wrong with the proposal because all fo your fears do not require this proposals and would be easier and with much less backlash without a public standard API.
  - choeger 3y ago
    Yeah right. "Don't worry, the leash you'll be wearing is a public standard.". You're either paid or delusional.
  - zb3 3y ago
    How can they get hardware attestation right now? They can't, that's why WEI is proposed.
    - cowl 3y ago
      Chrome has access to all kind of hardware information. they could have implemented that hidden in Chrome without all of this dust raising for a public Standard that gets scrutinized by everyone. Note that all discussion about chain of trust is there only because of all actors involved in a public standard, in case they wanted to just do this themselves they would just trust whatever the hidden chrome api would answer and that's that. much simpler, total control, no noise. For all that we know all kinds of closed source software are already doing something like this (especially ones who do a lot of natural network traffic so you cant even distinguish from the capturing raw data what is legit and what not.) For example, Netflix allows you to download a movie from their native apps but not from the browser, this is only because in the native Apps they have access to all kinds of hardware information and they can attest themselves about the "environment"
      - zb3 3y ago
        Having access to hardware information doesn't imply being able to transfer them to websites in a trusted way that the user can't modify. Chrome runs in the userspace, whereas I can write a kernel module which chrome can't interfere with (I did that for widevine in 2017!) that will emulate/lie to chrome about the hardware I have, and there's no way that the website owner could know whether I lie or not (this might require some effort on my part, but it's doable). Hardware based attestation was created precisely because the software based one can be bypassed.
        cowl 3y ago
drpixie 3y ago
> Google or any other Browser vendor do not have a say on how websites use or misuse features. Seriously? Would you give the kiddies sharp knives and loaded guns, and then be shocked when someone is injured? If we let this become available, we will all have to live with the consequences. We can see clearly what those consequences will be. Let's not be stupid.
- cowl 3y ago
  This overboard generalizations is what make me sure that everyone is just gut-reacting. Have you read the actual proposal (not an article about it)? In your knife-analogy, Google is producing sharp knifes for the cooks, not the children. the DRM crowd here is saying but what if the Cook uses the knife the attack the restaurant clients? Do you know of anyone seriously discussing that we should stop all production of knifes because someone might give one to a child? SO yes I agree, let's not be stupid.
  - dns_snek 3y ago
    > the DRM crowd here is saying but what if the Cook uses the knife the attack the restaurant clients? Your analogy once again falls apart because in this hypothetical scenario, the cooks have a decade-long history of attacking the guests every single time they get a hold of a new knife. In which case, yes, these cooks shouldn't have access to knives anymore. Of course that's not very practical, so perhaps they shouldn't be allowed to work as cooks anymore - i.e. separate Chrome from the ad business at the regulatory level and use Firefox or other alternatives on a personal level.
  - arlcode 3y ago
    Google is also the biggest ad vendor on the planet. They have every incentive to require websites running their ads to only allow ("google play" + other big players) verified software on their sites. They can a) prevent ad blockers and b) assure their customers that ads will be viewed by real humans. Not doing so once this is in place would be intentionally saying no to profit Why in the world would google care about anything else?
dns_snek 3y ago
> It seems Everyone is taking for granted the claim that this is about DRM. The claim is that websites (not Google) will use this signal to allow or deny access but this is already possible with various means. How about you offer a reasonable opposing viewpoint? It's hard to see this, at best, as anything other than an extremely naive viewpoint. Every feature that can be used to lock down content and/or spy on users, will be used to do just that. That's true for every single feature that exists today. Claiming otherwise borders on bad faith. > Google or any other Browser vendor do not have a say on how websites use or misuse features. That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it. > Many articles are just reapeating the "DRM" claim without explaining how is this different This is different because any meaningful "attestation about the environment the browser is running in" can only be achieved via a full chain of trust, starting with secure boot, which will allow Google (and websites you visit) to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software).
- cowl 3y ago
  > How about you offer a reasonable opposing viewpoint Read the proposal: https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md https://github.com/RupertBenWiser/Web-Environment-Integrity/... >That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it. Now who is arguing in bad faith? if you have read the proposal, it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them. > to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software). again there is no such thing proposed. The "attester" is not specifically Google. anyone can become an "attester". The chain of trust is a chain that trusts tokens not specific "things". if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester. The analogy here is the certificate Authorities. You may very well have a "let's encrypt" attester that democratizes the good parts (certification) without the bad parts (too much information) .
Adverblessly 3y ago
You know this is about DRM because that is explicitly the stated goal of this move. Apologies for just repeating a previous post I made about this but: The first goal of the proposal is to > Allow web servers to evaluate the authenticity of the device and honest representation of the software stack and the traffic from the device. That is, to give web servers the ability to Digitally restrict (or Manage) a user's Rights to access content on a device and software stack of their choice. The fact that this is DRM is unquestionable. What you seem to be taking at face value is Google's claim that this DRM will only be used to discriminate against bots and other abusive traffic, whereas everyone else is just pointing out that this technology can very easily be used for evil and that Google has every incentive and ability to do so. > what solution they would propose A man on the street stops you, points a gun to your head and instructs you to give him all of your money. How do you propose to solve the man's problem of lack of your money in his hands? Also, you cannot ask him to put down the gun before solving that problem.
- cowl 3y ago
  DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Netflix requiring you to login to view a movie is not DRM. Netflix offering a way to content owners to specify for example this movie can be seen but not download or this movie can be seen only once or this movie can not be fastforwarded, that is DRM. DRM means Publishers decide how their content gets consumed (on a case by case and publisher by publisher case). Nothing in this proposal gives publishers those means (beyond what is currently available). Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456"
  - Adverblessly 3y ago
    > DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Sure, if you redefine DRM to mean whatever you want it to mean, this is not DRM. I'm not even sure what authentication has to do with it if you prevent access to your website before I even got a chance to see it. > Netflix requiring you to login to view a movie is not DRM. Not sure where you came up with this strawman, I said nothing about requiring you to log in. I said "access content on a device and software stack of their choice.", so for example, limiting streaming quality to 720p on Linux, or blocking a user using FireFox, or blocking a user on Linux, or blocking a user with a custom kernel, or blocking a user without a TPM. > Nothing in this proposal gives publishers those means It gives them the means to discriminate based on hardware and software, for example by only trusting a single attestor of their choosing which only gives a trusted signal for whatever passes their hardware or software criteria. As an example, Google may decide that as a requirement to having their ads on your website, you must only trust a single attestor - "Google Play" (as named in the proposal), because otherwise you may be trusting an attestor that facilitates ad fraud, and we can't have that. Google naturally only treats devices running Chrome as trusted, how can they trust anything else that they don't own? Naturally, the same applies to their own websites, can't have you using FireFox to send people CP via gmail, right? Do you want your website to be protected from bots via Google's reCaptcha? I'm sure they know how to decide which access attempt belongs to a valid user or not. And they'll be happy to cooperate with Cloudfront to make sure everyone online is equally safe. Obviously, it is also on Google to protect users from websites that host botted content, so if you want to appear on search results and don't want the browser to give a scary warning when accessing your website, be sure to only trust the trustworthy attestor. And let's not get started on what happens if you want to take payment from users while "mitigating fraud"... > (beyond what is currently available) Right, the justification to do more evil is that we already do some evil, I'm convinced. > Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456" In just this specific example you prove yourself wrong. You can use the generic "trusted/not trusted" signal to decide "movie 123 is OK for not trusted, but movie 456 we will restrict to trusted only".
wzdd 3y ago
The difference is that currently you can lie. You can identify the fingerprinting techniques being used, and work around them. yt-dlp already does something like this, for example. In Android, there was a lot of support for making your rooted / custom ROM system look like stock Android so you could still do banking. Now, depending on the level of Safetynet the app is using, you literally can't. I'm not arguing in favour of fingerprinting, just pointing out that prior to TPM-backed attestation you had control over your own device. With Android Safetynet attestation, you can't work around the problem because the attestation is backed by a root of trust which your custom ROM can't provide. Being able to supply your own thing doesn't matter, because everyone will just support the one that Google supplies. LineageOS is a good example of this; they have their own Safetynet implementation which has very little buy-in. WEI is effectively an extension of Safetynet to the Web. In summary, this is fundamentally different because it takes away your control of your own device.
- metalcrow 3y ago
  I mean, you can still lie, it's just made more difficult. Unless i'm missing something, running your OS under a hypervisor with a virtual TPM (or a forked browser with TPM access stubs and custom kernel drivers) still allows you to do whatever you want. It's certainly more difficult, and unreasonably so, but it's still quite possible. While i'm not familiar with Safteynet, i'm sure it's also possible to bypass it that way. The issue with this seems to be a sort of a restricting freedom for the greater good idea. If you restrict the ability of web developers to check security values and stuff, then they can't do some good things like improve security, but they also can't do any really bad things like block ad-blockers. But if you allow this access then you get the opposite.
  - wzdd 3y ago
    My understanding is that the vendor installs keys in the TPM which can't be retrieved. So no, a virtual TPM wouldn't work, because you don't have the vendor's keys. Or rather, you would be in the same situation as before, because you can install your own keys and then have the challenge of getting third parties to trust you.
deleted 3y ago
[deleted]

by cowl 3y ago

choeger 3y ago

> what does Google have to do with how websites choose to treat their users or what solution they would propose Google owns YouTube. Is it so hard to imagine that some product manager at YouTube counted the losses due to adblockers and asked a team in Chrome to prevent them?

cowl 3y ago
Youtube can and in some measure is already doing it without this new API. If google wanted to be sneaky they can provide whatever data they want to Youtube alone without making it a public standard. you see how all of these fears are contorted reasoning because you want to try to find something wrong with the proposal because all fo your fears do not require this proposals and would be easier and with much less backlash without a public standard API.
- choeger 3y ago
  Yeah right. "Don't worry, the leash you'll be wearing is a public standard.". You're either paid or delusional.
- zb3 3y ago
  How can they get hardware attestation right now? They can't, that's why WEI is proposed.
  - cowl 3y ago
    Chrome has access to all kind of hardware information. they could have implemented that hidden in Chrome without all of this dust raising for a public Standard that gets scrutinized by everyone. Note that all discussion about chain of trust is there only because of all actors involved in a public standard, in case they wanted to just do this themselves they would just trust whatever the hidden chrome api would answer and that's that. much simpler, total control, no noise. For all that we know all kinds of closed source software are already doing something like this (especially ones who do a lot of natural network traffic so you cant even distinguish from the capturing raw data what is legit and what not.) For example, Netflix allows you to download a movie from their native apps but not from the browser, this is only because in the native Apps they have access to all kinds of hardware information and they can attest themselves about the "environment"
    - zb3 3y ago
      Having access to hardware information doesn't imply being able to transfer them to websites in a trusted way that the user can't modify. Chrome runs in the userspace, whereas I can write a kernel module which chrome can't interfere with (I did that for widevine in 2017!) that will emulate/lie to chrome about the hardware I have, and there's no way that the website owner could know whether I lie or not (this might require some effort on my part, but it's doable). Hardware based attestation was created precisely because the software based one can be bypassed.
      - cowl 3y ago

drpixie 3y ago

> Google or any other Browser vendor do not have a say on how websites use or misuse features. Seriously? Would you give the kiddies sharp knives and loaded guns, and then be shocked when someone is injured? If we let this become available, we will all have to live with the consequences. We can see clearly what those consequences will be. Let's not be stupid.

cowl 3y ago
This overboard generalizations is what make me sure that everyone is just gut-reacting. Have you read the actual proposal (not an article about it)? In your knife-analogy, Google is producing sharp knifes for the cooks, not the children. the DRM crowd here is saying but what if the Cook uses the knife the attack the restaurant clients? Do you know of anyone seriously discussing that we should stop all production of knifes because someone might give one to a child? SO yes I agree, let's not be stupid.
- dns_snek 3y ago
  > the DRM crowd here is saying but what if the Cook uses the knife the attack the restaurant clients? Your analogy once again falls apart because in this hypothetical scenario, the cooks have a decade-long history of attacking the guests every single time they get a hold of a new knife. In which case, yes, these cooks shouldn't have access to knives anymore. Of course that's not very practical, so perhaps they shouldn't be allowed to work as cooks anymore - i.e. separate Chrome from the ad business at the regulatory level and use Firefox or other alternatives on a personal level.
- arlcode 3y ago
  Google is also the biggest ad vendor on the planet. They have every incentive to require websites running their ads to only allow ("google play" + other big players) verified software on their sites. They can a) prevent ad blockers and b) assure their customers that ads will be viewed by real humans. Not doing so once this is in place would be intentionally saying no to profit Why in the world would google care about anything else?

dns_snek 3y ago

> It seems Everyone is taking for granted the claim that this is about DRM. The claim is that websites (not Google) will use this signal to allow or deny access but this is already possible with various means. How about you offer a reasonable opposing viewpoint? It's hard to see this, at best, as anything other than an extremely naive viewpoint. Every feature that can be used to lock down content and/or spy on users, will be used to do just that. That's true for every single feature that exists today. Claiming otherwise borders on bad faith. > Google or any other Browser vendor do not have a say on how websites use or misuse features. That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it. > Many articles are just reapeating the "DRM" claim without explaining how is this different This is different because any meaningful "attestation about the environment the browser is running in" can only be achieved via a full chain of trust, starting with secure boot, which will allow Google (and websites you visit) to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software).

cowl 3y ago
> How about you offer a reasonable opposing viewpoint Read the proposal: https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md https://github.com/RupertBenWiser/Web-Environment-Integrity/... >That's settled then. Full filesystem, location, camera, and microphone access should therefore come on by default without a permission dialog. Why not bring back Java and Flash while we're at it! It's not the browser vendor's fault that websites are misusing it. Now who is arguing in bad faith? if you have read the proposal, it's clear that they are being careful and are upfront about the some potential misuses and the proposed handing of them. > to verify that your system is using a Google-approved bootloader to load a Google-approved operating system which only loads Google-approved drivers and Google-approved software (or worse, website-approved software). again there is no such thing proposed. The "attester" is not specifically Google. anyone can become an "attester". The chain of trust is a chain that trusts tokens not specific "things". if you for example would trust let's say Opera as the attester, Opera would need to trust windows or Linux or Android as the OS attester. The analogy here is the certificate Authorities. You may very well have a "let's encrypt" attester that democratizes the good parts (certification) without the bad parts (too much information) .

Adverblessly 3y ago

You know this is about DRM because that is explicitly the stated goal of this move. Apologies for just repeating a previous post I made about this but: The first goal of the proposal is to > Allow web servers to evaluate the authenticity of the device and honest representation of the software stack and the traffic from the device. That is, to give web servers the ability to Digitally restrict (or Manage) a user's Rights to access content on a device and software stack of their choice. The fact that this is DRM is unquestionable. What you seem to be taking at face value is Google's claim that this DRM will only be used to discriminate against bots and other abusive traffic, whereas everyone else is just pointing out that this technology can very easily be used for evil and that Google has every incentive and ability to do so. > what solution they would propose A man on the street stops you, points a gun to your head and instructs you to give him all of your money. How do you propose to solve the man's problem of lack of your money in his hands? Also, you cannot ask him to put down the gun before solving that problem.

cowl 3y ago
DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Netflix requiring you to login to view a movie is not DRM. Netflix offering a way to content owners to specify for example this movie can be seen but not download or this movie can be seen only once or this movie can not be fastforwarded, that is DRM. DRM means Publishers decide how their content gets consumed (on a case by case and publisher by publisher case). Nothing in this proposal gives publishers those means (beyond what is currently available). Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456"
- Adverblessly 3y ago
  > DRM is not about access or not (that can and is being done with simple authenticated content). DRM is about what you can do with SPECIFIC contents. The MANAGE part in DRM. Sure, if you redefine DRM to mean whatever you want it to mean, this is not DRM. I'm not even sure what authentication has to do with it if you prevent access to your website before I even got a chance to see it. > Netflix requiring you to login to view a movie is not DRM. Not sure where you came up with this strawman, I said nothing about requiring you to log in. I said "access content on a device and software stack of their choice.", so for example, limiting streaming quality to 720p on Linux, or blocking a user using FireFox, or blocking a user on Linux, or blocking a user with a custom kernel, or blocking a user without a TPM. > Nothing in this proposal gives publishers those means It gives them the means to discriminate based on hardware and software, for example by only trusting a single attestor of their choosing which only gives a trusted signal for whatever passes their hardware or software criteria. As an example, Google may decide that as a requirement to having their ads on your website, you must only trust a single attestor - "Google Play" (as named in the proposal), because otherwise you may be trusting an attestor that facilitates ad fraud, and we can't have that. Google naturally only treats devices running Chrome as trusted, how can they trust anything else that they don't own? Naturally, the same applies to their own websites, can't have you using FireFox to send people CP via gmail, right? Do you want your website to be protected from bots via Google's reCaptcha? I'm sure they know how to decide which access attempt belongs to a valid user or not. And they'll be happy to cooperate with Cloudfront to make sure everyone online is equally safe. Obviously, it is also on Google to protect users from websites that host botted content, so if you want to appear on search results and don't want the browser to give a scary warning when accessing your website, be sure to only trust the trustworthy attestor. And let's not get started on what happens if you want to take payment from users while "mitigating fraud"... > (beyond what is currently available) Right, the justification to do more evil is that we already do some evil, I'm convinced. > Verifying the authenticity of a device in this case is a generic "trusted/not trusted" not "OK for movie 123/KO for skipping on movie 456" In just this specific example you prove yourself wrong. You can use the generic "trusted/not trusted" signal to decide "movie 123 is OK for not trusted, but movie 456 we will restrict to trusted only".

wzdd 3y ago

The difference is that currently you can lie. You can identify the fingerprinting techniques being used, and work around them. yt-dlp already does something like this, for example. In Android, there was a lot of support for making your rooted / custom ROM system look like stock Android so you could still do banking. Now, depending on the level of Safetynet the app is using, you literally can't. I'm not arguing in favour of fingerprinting, just pointing out that prior to TPM-backed attestation you had control over your own device. With Android Safetynet attestation, you can't work around the problem because the attestation is backed by a root of trust which your custom ROM can't provide. Being able to supply your own thing doesn't matter, because everyone will just support the one that Google supplies. LineageOS is a good example of this; they have their own Safetynet implementation which has very little buy-in. WEI is effectively an extension of Safetynet to the Web. In summary, this is fundamentally different because it takes away your control of your own device.

metalcrow 3y ago
I mean, you can still lie, it's just made more difficult. Unless i'm missing something, running your OS under a hypervisor with a virtual TPM (or a forked browser with TPM access stubs and custom kernel drivers) still allows you to do whatever you want. It's certainly more difficult, and unreasonably so, but it's still quite possible. While i'm not familiar with Safteynet, i'm sure it's also possible to bypass it that way. The issue with this seems to be a sort of a restricting freedom for the greater good idea. If you restrict the ability of web developers to check security values and stuff, then they can't do some good things like improve security, but they also can't do any really bad things like block ad-blockers. But if you allow this access then you get the opposite.
- wzdd 3y ago
  My understanding is that the vendor installs keys in the TPM which can't be retrieved. So no, a virtual TPM wouldn't work, because you don't have the vendor's keys. Or rather, you would be in the same situation as before, because you can install your own keys and then have the challenge of getting third parties to trust you.

deleted 3y ago

[deleted]