* I am not a contributor to the repo, and stepped in as chair on the repo after writing this, to help the engineers contributing to it deal with clear spam & abuse cases. I wrote this post with WEI in mind, but nothing about it is specific to this proposal, and could've been applied to multiple past proposals (and probably future ones), either from Google or from other standards participants.
A couple of things I should've included in that post and didn't:
* It's important to actually read and understand the proposal before objecting to it. For example, WEI has nothing to do with ad-blockers or DRM (in the sense that the content itself is not restricted, unlike EME). It does have real eco-system risks that the proposal would need to address before moving forward. Objecting to the latter makes sense. Objecting to the former is easy to dismiss as a misunderstanding.
* At the end of the day, in the case of Chromium, your goal is not necessarily to convince the proposal's proponents, but the API owners [2], many of whom are not Google employees.
Your P.S. really shows that you are not really acting in good faith here. It might be good to take a step back and think about the reaction people are having. Consider the possibility that the problem might not be that the whole rest of the world is acting like toddlers, but rather that there is something fundamentally and objectively problematic with WEI and that the community is having a very strong negative reaction to it for some good reason.
It really says something that when faced with _universal_ opposition, he still asked people to either provide “constructive” criticism or GTFO, which is just a nicer way to say “we will push forward this no matter what you say”.
Writing "the whole rest of the world" shows you have lost perspective. Most of the world has never heard of this proposal. The people arguing against it don't represent them. (Nor do the people proposing it.)
Pretty deceptive to present yourself eager to discuss when you aggressively locked and closed issues where people present legitimate and well thought out concerns. If you don’t want to take responsibility for the proposal, withdraw your name from it.
> Political/ecosystem arguments are technical arguments.
No they are not. You don’t get to retcon a term just because people spotted a flaw in your argument.
Edit: I noticed you posted this while closing off the repo completely for new comments. You can’t make this up.
Software serves people. Underneath the question of what the technology does is always the question of what benefits who and why.
Is it technically correct for Hacker News to require login to upvote a story or comment? Mu; it's technically correct because it supports the ability to tie actions to actors, and that's correct because commenter history matters for the kind of forum Hacker News strives to be. Technical decisions are inextricable from what serves people.
And in that vein, the WEI team has been squelching comment channels because they've become low-value noise channels and dogpile opportunities. This isn't a design that the team in charge of it is choosing to do or not do by the number of angry GitHub posts they get, so that channel is now noise because they don't have someone to perch on the channel and filter novel information from me-too "Don't do" repeats.
I don't believe in attacking individuals for what is a systemic issue.
> It's important to actually read and understand the proposal before objecting to it.
How do you assume that the people who criticize it didn't read it? I saw many arguments based on the proposal text. I myself read it thrice before making my first post.
> For example, WEI has nothing to do with ad-blockers or DRM (in the sense that the content itself is not restricted, unlike EME)
From what I can see, the webpage needs to return the token to the server before it decides to respond [1]. True that proposal doesn't say if the server should respond or not. But the mere possibility that the server can deny a response based on the token (or its absence) means that it will be used. How is this not DRM? And how is this not dangerous to the open web?
> I don't believe in attacking individuals for what is a systemic issue.
I appreciate that!
> From what I can see, the webpage needs to return the token to the server before it decides to respond [1]. True that proposal doesn't say if the server should respond or not. But the mere possibility that the server can deny a response based on the token (or its absence) means that it will be used. How is this not DRM? And how is this not dangerous to the open web?
This could definitely be risky for the open web, and that's an argument to put forward [1]. In my book this is not a blocker for being able to discuss any of this. (but could be a blocker for shipping this proposal without proper mitigation)
At the same time, I perceive DRM as a way to control access and ability to copy copyrighted material. I couldn't find anything in this proposal that enabled any of that.
So we are in agreement that WEI poses a serious threat to open web. Now let's get to the DRM part:
> At the same time, I perceive DRM as a way to control access and ability to copy copyrighted material.
That is merely the stated objective of DRM. However, it's well known and accepted that DRM schemes do the following as well:
1. Restrict where (device or application) the user can consume the content.
2. Restrict how long the user can consume the content.
Despite denials, I'm yet to see DRM schemes that don't do these as well. And everyone's concern regarding WEI is regarding point 1 and possibly point 2 as well. So, saying that WEI isn't DRM scheme is based on a narrow interpretation rather than a practical one.
The proposal creates a mechanism by which digital rights could be enforced, so it could be used as DRM.
Arguably, any ability to deny particular user agents is discrimination. Doing that in a cryptographically verifiable way is DRM or at least a primitive which can be used to build DRM.
> This could definitely be risky for the open web
Then it should not be done.
> At the same time, I perceive DRM as a way to control access and ability to copy copyrighted material. I couldn't find anything in this proposal that enabled any of that.
Whether the proposal specifically mentions copyrights or DRM is immaterial; I don't even know why you would make this point.
> In my book this is not a blocker for being able to discuss any of this
First of all, respectfully, "your book" is not relevant; you are acting in your capacity as a chair, are you not? Second of all, yes, if something is morally abhorrent, it is not even worth discussion. You are still not understanding why people are reacting this way. Please, again, I implore you to reconsider your interpretation of these responses; people are trying to tell you that this proposal is SO dangerous, and SO bad, that it should be deleted from existence and never discussed again.
> I am not a contributor to the repo, and stepped in as chair on the repo after writing this
Nobody is missing this; you're defending this work. You can't both defend the work itself and place yourself outside of the process as a "chair."
> If you're objecting to the goals of the proposal [1], it'd serve you better to outline which goals are objectionable and why
Many technologists don't have the clout or sometimes the charisma to explain within this rigid framework you have presented why this proposal is such a bad idea. That doesn't mean their feedback should be dismissed outright.
> It's important to actually read and understand the proposal before objecting to it. For example, WEI has nothing to do with ad-blockers or DRM
But it is DRM because it can be used, in effect, like DRM. You are missing the point that most of the community sees this as DRM-like technology, with all of its warts, whether you agree with that conclusion or not.
> At the end of the day, in the case of Chromium, your goal is not necessarily to convince the proposal's proponents, but the API owners
Okay, so, in summary, your points are that the feedback you've read is (1) not yours to address but you are addressing anyway, (2) not valuable within your own value framework (??), and (3) that the opposing viewpoints are misplaced in commenting on the repo which holds the proposal?
> I'd love to discuss this with y'all like professional adults. Can we do that?
Sure, when do you intend to start? Suggesting that opposing viewpoints are "unprofessional" prima-facie doesn't seem like the best way to win hearts and minds.
Edit: Yoav, I'd be happy to respond to you in good faith as I've done here once Hckrnews lets me post it.
Yeah, the author has to resort to tone-policing because they have no good rebuttals for the criticism being received so they are trying to invalidate and dismiss said criticism due to its 'tone'.
> Nobody is missing this; you're defending this work. You can't both defend the work itself and place yourself outside of the process as a "chair."
I'm not defending the work. I'm defending the venue, to enable standard proposal work to happen in public (and get feedback from the community).
> But it is DRM because it can be used, in effect, like DRM. You are missing the point that most of the community sees this as DRM-like technology, with all of its warts, whether you agree with that conclusion or not.
OK, maybe I'm missing something then. Can you explain to me in what ways this is DRM?
> 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.
> I'm not defending the work. I'm defending the venue, to enable standard proposal work to happen in public (and get feedback from the community).
You mean the repo which is closed for new issues, on which Google has shut down commentary, past the weekend deadline it promised for re-opening commentary? This is the open work process under examination?
> OK, maybe I'm missing something then. Can you explain to me in what ways this is DRM?
I would be glad to take a crack at this, but smarter people have spent their whole lives advancing humankind's understanding on this topic. They should speak on it, not me. I have my own private suspicions about what they will say though.
It's establishing whether I have the right to view or use this site, as determined by whether some far off entity such as a Google approves of my computer or not.
There is no reason to expect the community to be “tolerant” and “kind” to an intolerant proposal.
Get off your high horse of neutrality, because it’s not neutral. Proposals like this will be treated like a hostile attack because that is what they are. If you’re unable to see that then that problem is on you not _everyone else_.
This is extremely similar to the same arguments leftists give of _not giving a platform to fascists_. Giving that platform is legitimizing them.
This proposal is being seen as a technological fascist attack on the web, and you’re getting that signal. Except you’re categorizing that signal as noise.
>* If you're objecting to the goals of the proposal [1], it'd serve you better to outline which goals are objectionable and why. Mozilla folks did a good job at articulating that in https://github.com/mozilla/standards-positions/issues/852#is...
Well, you asked for it, so here goes. WEI (IIUC) requires (at least the proposal claims such a thing) "attestation" of my devices in order to ensure that advertisements (and the sites they are displayed on) are actually viewed by humans and not bots engaged in gaming the ad system and 3rd party content creation.
The proposal would require me to give (without choice or recompense) data, CPU cycles, network bandwidth and, most importantly some portion of my privacy to accomplish such "attestation."
Without allowing such intrusions on my private property (i.e., my devices), the proposal as it stands, could (and with wide adoption, would) block me from accessing sites of my choosing. And that's antithetical to the idea of the open internet.
I provide a bit more detail in this comment[0] in a different discussion[1] of this proposal, wherein I detail that these are issues between advertisers and Google that have absolutely nothing to do with me.
Why should I be required to donate CPU cycles, storage, bandwidth and give up some privacy so a multi-hundred billion dollar corporation can better serve its customers (again, neither of whom I have any sort of business relationship with) and improve its financial performance?
Perhaps you could enlighten me on what benefit WEI has for anyone other than Google or its customers (that'd be advertisers)?
Ironic everyone is, and has been, discussing this as "adults" except the author (with passive-aggressive tone and unprofessional P.S.).
Perhaps look in the mirror and get off the high horse? If Google bestows someone with some middle-managerial role, they don't get to assume everyone in the outside world is also one of their reports and have to suck up to them otherwise their Perf rating would suffer.
Do you know why this proposal is over a public repo which is not a part of any official open web group discussion?
Why would anyone with legitimate concerns for unforseen consequences which would occur if the proposal or any descendants of it to turn to a standard would want to be constructive about it? Particularly considering the concern if they want to stop it on the tracks?
Why would you not like to get the legal related feedback, don't the legalities dictate technical constraints? Or do you think this would go on with or without being in the legal?
> Do you know why this proposal is over a public repo which is not a part of any official open web group discussion?
A typical workflow for standard proposals is: personal repo => incubation venue => official working group
This proposal is so early stage that it hasn't passed the "personal repo" phase just yet.
> Why would anyone with legitimate concerns for unforseen consequences which would occur if the proposal or any descendants of it to turn to a standard would want to be constructive about it? Particularly considering the concern if they want to stop it on the tracks?
"being constructive" doesn't mean being supportive. If the goal is objectionable and you want the work to stop, articulating why it's objectionable is your best bet at getting what you want.
> Why would you not like to get the legal related feedback, don't the legalities dictate technical constraints? Or do you think this would go on with or without being in the legal?
Actual legal concerns obviously get addressed (and doing that goes through legal counsels). But throwing "legal words" into feedback significantly increases the friction of answering it, without increasing its weight or validity. That can decrease the chances of it getting addressed.
But I believe you and I have a pretty different understanding about "constructive criticism". I don't believe "non-supportive and constructive" is enough in this case. I don't even believe that to be possible.
You can't "construct" while you want to "destruct".
Please stop obfuscating the issue. You're doing morally repugnant work, and no amount of tone policing will change that. Please take the advice already given to you in multitudes: Don't
A few clarifications:
* I am not a contributor to the repo, and stepped in as chair on the repo after writing this, to help the engineers contributing to it deal with clear spam & abuse cases. I wrote this post with WEI in mind, but nothing about it is specific to this proposal, and could've been applied to multiple past proposals (and probably future ones), either from Google or from other standards participants.
* Political/ecosystem arguments are technical arguments. See https://blog.yoav.ws/posts/web_platform_change_you_do_not_li...
* If you're objecting to the goals of the proposal [1], it'd serve you better to outline which goals are objectionable and why. Mozilla folks did a good job at articulating that in https://github.com/mozilla/standards-positions/issues/852#is...
A couple of things I should've included in that post and didn't:
* It's important to actually read and understand the proposal before objecting to it. For example, WEI has nothing to do with ad-blockers or DRM (in the sense that the content itself is not restricted, unlike EME). It does have real eco-system risks that the proposal would need to address before moving forward. Objecting to the latter makes sense. Objecting to the former is easy to dismiss as a misunderstanding.
* At the end of the day, in the case of Chromium, your goal is not necessarily to convince the proposal's proponents, but the API owners [2], many of whom are not Google employees.
[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/... [2] https://blog.chromium.org/2019/11/intent-to-explain-demystif...
P.S. I'd love to discuss this with y'all like professional adults. Can we do that?