So, you don't like a web platform proposal(blog.yoav.ws)
blog.yoav.ws
So, you don't like a web platform proposal
https://blog.yoav.ws/posts/web_platform_change_you_do_not_like/
113 comments
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.
> 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.
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?
[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/...
> 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?
[1] https://github.com/RupertBenWiser/Web-Environment-Integrity/...
> 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.
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
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.
[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
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.
> 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.
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.
If we delete it for existence it'll just come up again; the benefits for web developers are extremely compelling.
> 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.
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'.
What a lazy rhetorical device.
What a lazy rhetorical device.
> 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?
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?
(Note that I'm not the parent)
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.
Can you explain in what ways this is not DRM?
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.
Can you explain in what ways this is not DRM?
There are 11 issues on the repo matching a search for "DRM".
Please list all the comments with the word "DRM" you read, and justify any you skipped.
Then we can write an explanation meeting your requirements. I hope you'll read that one!
Please list all the comments with the word "DRM" you read, and justify any you skipped.
Then we can write an explanation meeting your requirements. I hope you'll read that one!
> 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.
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.
Please listen to the feedback you have universally gotten from the community. Stop.
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.
Have you heard of the paradox of tolerance?
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.
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)?
[0] https://news.ycombinator.com/item?id=36860125
[1] https://news.ycombinator.com/item?id=36857032
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)?
[0] https://news.ycombinator.com/item?id=36860125
[1] https://news.ycombinator.com/item?id=36857032
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.
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?
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.
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.
First thank you answering openly.
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".
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".
This proposal is so early stage that it hasn't passed the "personal repo"
phase just yet.
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
Hey snowflake,
Your proposal sucks, get over it. You have received plenty of thoughtful feedback and you are not a victim.
Veiling contempt for your audience should be a bannable offence here.
Your proposal sucks, get over it. You have received plenty of thoughtful feedback and you are not a victim.
Veiling contempt for your audience should be a bannable offence here.
[deleted]
> Don't assume consensus nor finished state
If someone presents me with an document proposing their right and ability to punch me in the throat whenever they desire, it’s either, and then when I protest state that it’s ”just a joke bro”, it’s either
1. a bad joke I’m not in on
2. A real and serious proposition
Now, when the person making the proposal has a reputation for punching people in the throat, it’s very clearly not the former.
> We're all humans
No we’re not: one side is a massive corporation with a profit motive and no morals or personhood. They don’t get obfuscate their intent and escape criticism by foisting the actual submission onto some random dev. The devs in question are either implicit with this-in which case they deserve no sympathy, or they are not, and should realise they’re being used as sacrificial lambs. Neither case is reason to use kid-gloves.
> Technical grounds
This arguments is meaningless in this situation. The proposal is bad on fundamental intent grounds, technical arguments have nothing to do with it.
> Considered alternatives
Yeah here’s a considered alternative: Don’t do this. There we go, just as much justification and technical validity as the original proposal. Now, as I am reasonable, I will only accept counter arguments in the form of interpretive dance, performed in person, in 15 minutes time, in the sub-basement of my nearest Antarctic station. All other responses are rude and off topic.
If someone presents me with an document proposing their right and ability to punch me in the throat whenever they desire, it’s either, and then when I protest state that it’s ”just a joke bro”, it’s either
1. a bad joke I’m not in on
2. A real and serious proposition
Now, when the person making the proposal has a reputation for punching people in the throat, it’s very clearly not the former.
> We're all humans
No we’re not: one side is a massive corporation with a profit motive and no morals or personhood. They don’t get obfuscate their intent and escape criticism by foisting the actual submission onto some random dev. The devs in question are either implicit with this-in which case they deserve no sympathy, or they are not, and should realise they’re being used as sacrificial lambs. Neither case is reason to use kid-gloves.
> Technical grounds
This arguments is meaningless in this situation. The proposal is bad on fundamental intent grounds, technical arguments have nothing to do with it.
> Considered alternatives
Yeah here’s a considered alternative: Don’t do this. There we go, just as much justification and technical validity as the original proposal. Now, as I am reasonable, I will only accept counter arguments in the form of interpretive dance, performed in person, in 15 minutes time, in the sub-basement of my nearest Antarctic station. All other responses are rude and off topic.
ahahahahah(1)
The section, "Don't assume a hidden agenda", is a rather irrelevant response to the outrage, because the agenda we don't like is written out in the proposal. It's not hidden, it's rather transparent and it's the dystopian nightmare we want to avoid.
From the proposal:
> Users often depend on websites trusting the client environment they run in. This trust may assume that the client environment is honest about certain aspects of itself, keeps user data and intellectual property secure, and is transparent about whether or not a human is using it. This trust is the backbone of the open internet, critical for the safety of user data and for the sustainability of the website’s business.
> Some examples of scenarios where users depend on client trust include:
> Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.
> Users want to know they are interacting with real people on social websites but bad actors often want to promote posts with fake engagement (for example, to promote products, or make a news story seem more important). Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment.
> Users playing a game on a website want to know whether other players are using software that enforces the game's rules.
> Users sometimes get tricked into installing malicious software that imitates software like their banking apps, to steal from those users. The bank's internet interface could protect those users if it could establish that the requests it's getting actually come from the bank's or other trustworthy software.
From the proposal:
> Users often depend on websites trusting the client environment they run in. This trust may assume that the client environment is honest about certain aspects of itself, keeps user data and intellectual property secure, and is transparent about whether or not a human is using it. This trust is the backbone of the open internet, critical for the safety of user data and for the sustainability of the website’s business.
> Some examples of scenarios where users depend on client trust include:
> Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots. This creates a need for human users to prove to websites that they're human, sometimes through tasks like challenges or logins.
> Users want to know they are interacting with real people on social websites but bad actors often want to promote posts with fake engagement (for example, to promote products, or make a news story seem more important). Websites can only show users what content is popular with real people if websites are able to know the difference between a trusted and untrusted environment.
> Users playing a game on a website want to know whether other players are using software that enforces the game's rules.
> Users sometimes get tricked into installing malicious software that imitates software like their banking apps, to steal from those users. The bank's internet interface could protect those users if it could establish that the requests it's getting actually come from the bank's or other trustworthy software.
Exactly, the agenda is everything. It's very difficult to convince a megacorp to act against its profit motive. The proposal exists within a cultural and economic context, you can't just ignore that.
The last one is especially hilarious since ads are the most common vector to install malware.
The advice is relevant then. You can argue about the stated agenda and use cases instead of assuming a hidden one.
Whether there is a hidden agenda or not, the authors of the spec can just reply, "that isn't the agenda" and ignore everything in your comment that followed from it.
Whether there is a hidden agenda or not, the authors of the spec can just reply, "that isn't the agenda" and ignore everything in your comment that followed from it.
As far as I can tell, the criticism against the proposal was mostly surrounding the clearly stated goals of the proposal, such as protecting intellectual property. Didn't see much wild speculation, even though the internet is usually filled to the brim with it. So this advice as general advice makes sense, but is odd as a response to this situation.
The listed use-cases are not what I typically see complaints about.
What I do see a lot: * This will be used to detect and block ad blockers. * Open source users can't do attestation and will get locked out of parts of the web.
These are not goals of this proposal from what I can tell. And there are indeed discussions how to avoid those negative externalities.
What I do see a lot: * This will be used to detect and block ad blockers. * Open source users can't do attestation and will get locked out of parts of the web.
These are not goals of this proposal from what I can tell. And there are indeed discussions how to avoid those negative externalities.
"Users like visiting websites that are expensive to create and maintain, but they often want or need to do it without paying directly. These websites fund themselves with ads, but the advertisers can only afford to pay for humans to see the ads, rather than robots."
That's as clear as day, they won't let you view the page with ad blocking.
That's as clear as day, they won't let you view the page with ad blocking.
Dumb question: wouldn’t this actually reduce ad revenue as you would be eliminating ad fraud for which providing platforms collect money?
It would reduce the number of fraudulent clicks and non-human views, but then if you can verify the eyeballs and cursor on the other side are human, presumably that would increase the cost per impression and per click, so it may increase revenue.
While I fully understand the feeling of the author being a Googler doing their job, being a cog in the machine and launching something to advance their promo case, would be visibly upset that people who actually care about the outcome are actively fighting their project, I also think from the users' perspective, dealing with a powerful corporation, it is the right thing to do to bury this type of danger as soon as possible.
(The piece where the author suggests focusing on "technical arguments" when the issue at hand is fundamentally political is frankly laughable; can't really tell if it is naïveté or deception.)
(The piece where the author suggests focusing on "technical arguments" when the issue at hand is fundamentally political is frankly laughable; can't really tell if it is naïveté or deception.)
"It is difficult to get a man to understand something when his salary depends on his not understanding it."
-Upton Sinclair
"It is useless to argue with a man whose opinion is based upon a personal or pecuniary interest; the only way to deal with him is to outvote him." -William Jennings Bryan
"Hear, hear! It’s all a question of trusts and monopolies. Doctors have a monopoly of medicine just as parsons have of God. You can’t get a parson to admit the arguments of an agnostic, because his salary depends on his not letting the agnostic refute him; and you can’t get an ordinary doctor to look kindly on psychoanalysis or autosuggestion because their success would make him superfluous. All this is not a question of the Life Force at all; it is a question of bread and butter." -C. E. M. Joad
"It is useless to argue with a man whose opinion is based upon a personal or pecuniary interest; the only way to deal with him is to outvote him." -William Jennings Bryan
"Hear, hear! It’s all a question of trusts and monopolies. Doctors have a monopoly of medicine just as parsons have of God. You can’t get a parson to admit the arguments of an agnostic, because his salary depends on his not letting the agnostic refute him; and you can’t get an ordinary doctor to look kindly on psychoanalysis or autosuggestion because their success would make him superfluous. All this is not a question of the Life Force at all; it is a question of bread and butter." -C. E. M. Joad
Couldnt agree more, the 'make technical arguments' nonsense when WEI, and many similar issues, arent problematic for technical reason is ridiculous.
>The piece where the author suggests focusing on "technical arguments" when the issue at hand is fundamentally political is frankly laughable
It is essentially just asking for constructive feedback. When people just say not to do it, insult the author, or make assumptions about the proposal that aren't true the comments are not actionable.
Even if an issue is political you can still make a constructive argument on the risks that adopting the proposal has.
It is essentially just asking for constructive feedback. When people just say not to do it, insult the author, or make assumptions about the proposal that aren't true the comments are not actionable.
Even if an issue is political you can still make a constructive argument on the risks that adopting the proposal has.
Here's how they respond to 'constructive arguments': https://news.ycombinator.com/item?id=36855429 . Especially this part: https://danshumway.com/blog/chrome-autoplay/
From the first link:
> according to Google there's no such thing as a harmful feature and Google's approach is never wrong; it just might need refining
This is some grade-A toxic behaviour from google. It gives the same vibes as the infuriatingly phrased: “oh sweetly you just don’t understand”
> according to Google there's no such thing as a harmful feature and Google's approach is never wrong; it just might need refining
This is some grade-A toxic behaviour from google. It gives the same vibes as the infuriatingly phrased: “oh sweetly you just don’t understand”
It’s asking for feedback the author knows how to deal with (and disregard).
You know, if your government body of choice came up with a terrible idea in a draft bill and enraged the population, it would not be appropriate for them to go on TV and say “the population should offer constructive criticism in the form of legal arguments”. So what the fuck is this guy saying exactly, that you feel is a valid approach to handling public outcry?
You know, if your government body of choice came up with a terrible idea in a draft bill and enraged the population, it would not be appropriate for them to go on TV and say “the population should offer constructive criticism in the form of legal arguments”. So what the fuck is this guy saying exactly, that you feel is a valid approach to handling public outcry?
>It’s asking for feedback the author knows how to deal with (and disregard).
Yes, and you can see how many people are being ignored. The article is a guide on how you can avoid being ignored and actually contribute to the process of standardization.
>So what the fuck is this guy saying exactly, that you feel is a valid approach to handling public outcry?
For example, people may think coming up with legal arguments may be an effective way to engage in the proposal and try to shut it down. The article describes that legal arguments will not be productive.
Yes, and you can see how many people are being ignored. The article is a guide on how you can avoid being ignored and actually contribute to the process of standardization.
>So what the fuck is this guy saying exactly, that you feel is a valid approach to handling public outcry?
For example, people may think coming up with legal arguments may be an effective way to engage in the proposal and try to shut it down. The article describes that legal arguments will not be productive.
Yeah, no, I’ve been in this game before as well.
The author’s perspective is that their team is right, the use case is valid and MUST be addressed, and if there is an issue in the proposal, it’s a fixable technical issue but the essence of the thing has to happen.
The author will never accept that the premise is wrong, because that would not be constructive feedback.
The premise is wrong. Thus, this blog post is useless, and this defence of “the process” is an utter waste of time for you and me alike.
The author’s perspective is that their team is right, the use case is valid and MUST be addressed, and if there is an issue in the proposal, it’s a fixable technical issue but the essence of the thing has to happen.
The author will never accept that the premise is wrong, because that would not be constructive feedback.
The premise is wrong. Thus, this blog post is useless, and this defence of “the process” is an utter waste of time for you and me alike.
> The article is a guide on how you can avoid being ignored and actually contribute to the process of standardization.
But the article assumes that the goals are acceptable, so the only valid feedback is about the best way to accomplish those goals. There is no room there for people who think the goals themselves are unacceptable.
I think that what they're wanting to do is terrible. Why in the world would I want to contribute to standardizing the method of accomplishing them?
But the article assumes that the goals are acceptable, so the only valid feedback is about the best way to accomplish those goals. There is no room there for people who think the goals themselves are unacceptable.
I think that what they're wanting to do is terrible. Why in the world would I want to contribute to standardizing the method of accomplishing them?
What if my problem is with the existence of the standard itself instead of implementation details?
Then I would suggest that you calm down and be open to creating a safe environment for people to share their ideas. People should be free to propose whatever they want for the web. You shouldn't take issue with bad proposals merely existing.
> You shouldn't take issue with bad proposals merely existing.
I disagree. If you don't take issue with bad proposals, it increases the chances that those bad proposals will be implemented.
I disagree. If you don't take issue with bad proposals, it increases the chances that those bad proposals will be implemented.
I don't think a safe environment should preclude saying "what the hell man". People should be free to react however they want to proposals for the web that would affect them. Anyone can write a proposal, but a proposal written by Googlers for Google has oomph than a proposal written by some guy.
Which might be wrong of course. The legal argument that this smells of monopoly abuse and might be a factor in the coming forced split of alphabet could actually stop such proposals most effectively.
Can you provide an example of feedback that hasn't been ignored?
1. This isn't external, it's internal
2. It's not feedback, it's a bug report on something being broken
You don't get a gold star for being like "See, they're listening!" when they allow people internally involved in the project the privilege of having their bug reports heard.
The proposal is de-facto bad. The goals it wants to achieve are bad. There is no "technical argument", just like there's no "technical argument" to being against a proposal that says you must share all your passwords with me. Stop the sealioning.
2. It's not feedback, it's a bug report on something being broken
You don't get a gold star for being like "See, they're listening!" when they allow people internally involved in the project the privilege of having their bug reports heard.
The proposal is de-facto bad. The goals it wants to achieve are bad. There is no "technical argument", just like there's no "technical argument" to being against a proposal that says you must share all your passwords with me. Stop the sealioning.
Exactly "give constructive and technical feedback" means "we will make this thing, either give feedback that would add to it in s technical way or shut up"
If the purpose the proposal is trying to accomplish is itself highly objectionable, the only reasonable constructive feedback is "don't do it".
I agreed with you, Yoav, when you posted your rant about gRPC and Chrome (because of the trailers debacle). Here was a case where Google prevented innovation at Google for unclear and selfish reasons, to the detriment of the community. You weren't wrong about how that decision was made with too few voices in the room. That decision was made in a vacuum, and Google and the community suffered.
WEI is a case where you should apply this same thinking. If the response is resoundingly negative, to the point where the conversation degrades, your counterparty may be trying to signal a deeper level of panic than you acknowledge. The point of people posting legalese-style threats is to get Google to disengage. I think the opponents of this proposal have little interest in talking through it. They see it as a mortal threat to the Open Web, and I'm inclined to agree with them; under this framework, is it not our shared moral obligation to delay, obstruct, or otherwise oppose it by any means possible?
As a fan of your previous work, not a hater, I would respectfully implore you to think again.
WEI is a case where you should apply this same thinking. If the response is resoundingly negative, to the point where the conversation degrades, your counterparty may be trying to signal a deeper level of panic than you acknowledge. The point of people posting legalese-style threats is to get Google to disengage. I think the opponents of this proposal have little interest in talking through it. They see it as a mortal threat to the Open Web, and I'm inclined to agree with them; under this framework, is it not our shared moral obligation to delay, obstruct, or otherwise oppose it by any means possible?
As a fan of your previous work, not a hater, I would respectfully implore you to think again.
I love your response!
>That's great!! Getting involved in web platform discussions is essential to ensure it's built for and by everyone.
Yes, because Google is known for listening to public and talking to non-organisations without posting conversation killers like "the decision has been made and we're going forward with it. Thanks for your valuable feedback."
Yes, because Google is known for listening to public and talking to non-organisations without posting conversation killers like "the decision has been made and we're going forward with it. Thanks for your valuable feedback."
Yes, organizations love the mealy mouthed, weak feedback on their Github issue tracker because that's easy to ignore. Just say the issue is spammy, or hostile, then close it without addressing any of the issues.
What's harder to ignore (though still not impossible) is top articles on Reddit, HN, and even mainstream tech news sites, and a constant coverage on YouTube, podcasts, etc.
What's harder to ignore (though still not impossible) is top articles on Reddit, HN, and even mainstream tech news sites, and a constant coverage on YouTube, podcasts, etc.
Didn't Rust foundation went back and revised the stuff? As expected of a draft.
Community: We want more openess. Foundation: Here is a draft... Community: But perfect and without errors.
Community: We want more openess. Foundation: Here is a draft... Community: But perfect and without errors.
Oh just edited my comment, wanted to remove the Rust bit as it could (and it did :)) divert attention.
But to respond to your comment: I am not sure if they would have retreated if there wasn't a constant stream of negative coverage on platforms that they do not control (Twitter, YouTube, Twitch, podcasts, blogs).
The issue with the draft was that it was extremely out of touch and some were afraid that it wasn't just a small mistake, rather than a direction that the foundation wanted to take, no matter the backlash.
If my girlfriend came to me with a draft that she should be able to date the cute barista guy in our local coffee shop and staying in the relationship with me, the fact that it's just a draft would not make me any more confident in the future of our relationship.
But to respond to your comment: I am not sure if they would have retreated if there wasn't a constant stream of negative coverage on platforms that they do not control (Twitter, YouTube, Twitch, podcasts, blogs).
The issue with the draft was that it was extremely out of touch and some were afraid that it wasn't just a small mistake, rather than a direction that the foundation wanted to take, no matter the backlash.
If my girlfriend came to me with a draft that she should be able to date the cute barista guy in our local coffee shop and staying in the relationship with me, the fact that it's just a draft would not make me any more confident in the future of our relationship.
This is a terrible take.
It is completely understandable from the perspective of Google contributors, as it is the least effort path for them to continue making profits, but shying away from criticism under the guise of “constructive discussion” is a really old tactic, and is well known by other names (such as “sealioning” when the strategy involves irritating the other party with excessive questions).
It is completely understandable from the perspective of Google contributors, as it is the least effort path for them to continue making profits, but shying away from criticism under the guise of “constructive discussion” is a really old tactic, and is well known by other names (such as “sealioning” when the strategy involves irritating the other party with excessive questions).
The central issue seems to be that Yoav frames this as a technical discussion. That people are unhappy with how Google tries to achieve the goal.
> Focusing on use cases would enable you to distill the essence of the proposal, and potentially propose alternatives that still address them without the bits you find harmful or risky.
But I think its obvious from discourse around the proposal that the goal itself is the problem. People aren't "constructively involved", not because they don't know how, they aren't because they don't want to construct anything. They think your goal is bad. They want you to stop.
> Focusing on use cases would enable you to distill the essence of the proposal, and potentially propose alternatives that still address them without the bits you find harmful or risky.
But I think its obvious from discourse around the proposal that the goal itself is the problem. People aren't "constructively involved", not because they don't know how, they aren't because they don't want to construct anything. They think your goal is bad. They want you to stop.
It’s passive-aggressive as hell and I can tell this guy and the idea as a whole are DOA… like even if this scheme didn’t give off strong Amp vibes, Google is the last company we want spearheading something like this. Stop trying to stay relevant, Google.
Google has already achieved this goal with their QUIC based HTTP/3. No implementation or use of HTTP/3 lib in any browser can connect to a webserver unless it gets the continued approval of a third party incorporated CA for TLS certs. With a 90 day renewal period that's basically just attestation of content every 90 days. If your site becomes illegal in an area (say, abortion information) then your CA TLS host can be pressured, cert revoked, and your site made unvisitable for all but uber geeks compiling their own HTTP/3 libs with special flags and linking them to $browser manually. There's no way to host a HTTP HTTP/3 site that's visitable. And no one minds. So...
Google could have avoided all of this blowback over WEI by simply calling it "HTTPS+ Everywhere" and pretending it helped user privacy only.
I'll grant there are a few more TLS CA options than possible WEI attestation options (if they really are to come from the OS vendors like the spec suggests). But not that many more and any legal pressure applicable to one is applicable to all. Both Google WEI and Google QUIC HTTP/3 are terrible and both need opposition or at least mitigation.
Google could have avoided all of this blowback over WEI by simply calling it "HTTPS+ Everywhere" and pretending it helped user privacy only.
I'll grant there are a few more TLS CA options than possible WEI attestation options (if they really are to come from the OS vendors like the spec suggests). But not that many more and any legal pressure applicable to one is applicable to all. Both Google WEI and Google QUIC HTTP/3 are terrible and both need opposition or at least mitigation.
Has one of the standard open ACME providers ever revoked a cert over content? Hellenic Academic and Research Institutions CA (HARICA) threatened to, but the renewal went through and everything is working fine on my end.
Can't you sign your own certificates? Whether people trust those is a different story. WAI is different because it breaks abstraction by asserting based on details which are otherwise invisible to the server.
You can. It's just that no browser that supports HTTP/3 will accept it as a legit endpoint with a valid root. So they won't connect to the HTTP/3 endpoint at all and you won't be able to access the HTTP/3 self-signed website.
And before anyone goes there, no, setting up your own root CA is not an option. Unless you get can Google/Apple/Mozilla/etc to include your root CA in their browser trust stores it doesn't help a random person visit your website at all.
And before anyone goes there, no, setting up your own root CA is not an option. Unless you get can Google/Apple/Mozilla/etc to include your root CA in their browser trust stores it doesn't help a random person visit your website at all.
>You can. It's just that no browser that supports HTTP/3 will accept it as a legit endpoint with a valid root. So they won't connect to the HTTP/3 endpoint at all and you won't be able to access the HTTP/3 self-signed website.
So long as there's a way to bypass verification or configure the trust store I'm okay with it. Is there official policy stating that this won't be possible or is this prediction?
As I understand it the primary reason for this push is that non-technical users too often skip security warnings, but I'm of the position there MUST at least be a way to bypass verification no matter what (through keyboard combos or a configurable trust store).
So long as there's a way to bypass verification or configure the trust store I'm okay with it. Is there official policy stating that this won't be possible or is this prediction?
As I understand it the primary reason for this push is that non-technical users too often skip security warnings, but I'm of the position there MUST at least be a way to bypass verification no matter what (through keyboard combos or a configurable trust store).
That's still self-signing. So the extra steps are immaterial to the point.
> Can't you sign your own certificates?
Self-signed certificates are banned in HTTP/2 onwards, which is really irritating when it is used for internal server-to-server communications.
You have to set up a Root CA certificate and use that to sign a second certificate. It's the same thing but with extra steps.
Self-signed certificates are banned in HTTP/2 onwards, which is really irritating when it is used for internal server-to-server communications.
You have to set up a Root CA certificate and use that to sign a second certificate. It's the same thing but with extra steps.
I've never had an issue using HTTP/2 with a self signed cert.
Huh? Self-signed certificates work with HTTP/2 in every browser I've tried it in, it just uses the usual trust-on-first-use system where you have to click past a warning.
That's still self-signing. So the extra steps are immaterial to the point.
> If your site becomes illegal in an area (say, abortion information) then your CA TLS host can be pressured, cert revoked
oh please... scare monger more. Like great, let's attach your petty little gripe to something that people care about in order to maybe get them on your side. except you can't show any real examples of it truly applying, so you just have to hint like "oh, this is possible, just imagine".
oh please... scare monger more. Like great, let's attach your petty little gripe to something that people care about in order to maybe get them on your side. except you can't show any real examples of it truly applying, so you just have to hint like "oh, this is possible, just imagine".
I take real issue with their occams razor comment under "Don't assume a hidden agenda" [0]
> it's often safe to assume that Occam's razor is applicable and the reason it is being proposed is that the team proposing it is trying to tackle the use cases the proposal handles
Just because something is initially conceived innocently and in response to a purely technical problem does not mean it wont be co-opted by the parent company that has a track record of establishing market hegemonies and anti-competitive practices. Humans didn't split the atom because we wanted to vaporize cities, we were merely curious about the "technical" fabric of reality as a natural pursuit of science. Furthermore, just because you're tasked with working on the technical problems, doesn't mean that technical problems are the only aspects that can or should be considered. It's plain as day how this will have non technical implications, and asserting those should be ignored for any reason - but especially in this context - is frankly insulting.
In other words, this seems to be a textbook case of "they were too preoccupied with whether or not they could, they didn't stop to ask if they should."
> To be more concrete and clear, personal attacks or threats addressed at the folks working on the platform are not OK
We agree on that at least.
[0]: https://blog.yoav.ws/posts/web_platform_change_you_do_not_li...
> it's often safe to assume that Occam's razor is applicable and the reason it is being proposed is that the team proposing it is trying to tackle the use cases the proposal handles
Just because something is initially conceived innocently and in response to a purely technical problem does not mean it wont be co-opted by the parent company that has a track record of establishing market hegemonies and anti-competitive practices. Humans didn't split the atom because we wanted to vaporize cities, we were merely curious about the "technical" fabric of reality as a natural pursuit of science. Furthermore, just because you're tasked with working on the technical problems, doesn't mean that technical problems are the only aspects that can or should be considered. It's plain as day how this will have non technical implications, and asserting those should be ignored for any reason - but especially in this context - is frankly insulting.
In other words, this seems to be a textbook case of "they were too preoccupied with whether or not they could, they didn't stop to ask if they should."
> To be more concrete and clear, personal attacks or threats addressed at the folks working on the platform are not OK
We agree on that at least.
[0]: https://blog.yoav.ws/posts/web_platform_change_you_do_not_li...
I'm sorry, but Occams razor tells me that Google proposed this to further strengthen their monopoly on the web browser market and make sure their ads and tracking cannot be avoided.
Seriously. When someone tells you that they don't have a hidden agenda, it means they absolutely have a hidden agenda. Normal people don't say that.
> and make sure their ads and tracking cannot be avoided.
Exactly. Their ads.
They are totally fine with people applying content filters for other companies.
> and make sure their ads and tracking cannot be avoided.
Exactly. Their ads.
They are totally fine with people applying content filters for other companies.
Normal people who are constantly subject to conspiracy theorists accusing them of having hidden agendas will certainly tell you that they don't have a hidden agenda. It's up to you to choose to join the conspiracy nuts or not.
They recently added telemetry to the go tools. The main guy responsible for the change wrote two blog posts first. Then they kept referring to it in the GitHub issue. They were able to thus frame it as if it were an opt-in vs opt-out discussion where everyone agreed that it was obviously necessary. Real people (our peers) kept referring dissenters to the blog posts like it is the Holy Bible.
I feel like I have to repeat this, since so much is at stake here, where it is about the preservation of the web as we know it today, at the peril of having it turned into yet another walled garden:
The only way around the dystopia this will lead to is to constantly and relentlessly shame and even harass all those involved in helping create it. The scolding in the issue tracker of that wretched "project" shall flow like a river, until the spirit of those pursuing it breaks, and the effort is disbanded.
And once the corporate hydra has regrown its head, repeat. Hopefully, enough practise makes those fighting the dystopia effective enough to one day topple over sponsoring and enabling organisations as a whole, instead of only their little initiatives leading down that path.
Not a pretty thing, but necessary.
The only way around the dystopia this will lead to is to constantly and relentlessly shame and even harass all those involved in helping create it. The scolding in the issue tracker of that wretched "project" shall flow like a river, until the spirit of those pursuing it breaks, and the effort is disbanded.
And once the corporate hydra has regrown its head, repeat. Hopefully, enough practise makes those fighting the dystopia effective enough to one day topple over sponsoring and enabling organisations as a whole, instead of only their little initiatives leading down that path.
Not a pretty thing, but necessary.
I thought Google was going to re-open public commenting on the repo after the weekend. It's now Tues in many parts of the world. Is it going to be opened up again as promised?
That whole article sounds like a parody, you can't seriously say that Google is interested in debates and technical merits on web proposals...
The Amp disaster being the best example of that. They do what they want according to their corporate goals and those proposals are just poorly made PR after the fact at best.
The Amp disaster being the best example of that. They do what they want according to their corporate goals and those proposals are just poorly made PR after the fact at best.
This is an awful, completely non bona fide piece. But I hope that by my upvoting it, people will see it and get a better understanding of the mindset that the engineers behind WEI have, and why this is all so problematic.
> Don't assume a hidden agenda
For google affiliated stuff that ship sailed a long time ago
For google affiliated stuff that ship sailed a long time ago
This article's advice makes more sense to me if I take it as tips for diplomacy as a representative in a high-stakes industry standards forum, where you can't necessarily call it out when someone is trying to pull a fast one.
However, when reporting back to your company, you can and must privately call out Machiavellian plots, sabotage, sloppiness, bad technical directions, business conflicts, arrogance, etc., to the people who need to know that's going on.
If you're not representing a company, but rather, the public interest, then I guess what role you take might depend partly on the overall ethical temperature of the forum, and what influence you can have. Can you do more good by trying to join the cabal circles, with all the necessary diplomacy? Or can you do more good by speaking candidly in public?
However, when reporting back to your company, you can and must privately call out Machiavellian plots, sabotage, sloppiness, bad technical directions, business conflicts, arrogance, etc., to the people who need to know that's going on.
If you're not representing a company, but rather, the public interest, then I guess what role you take might depend partly on the overall ethical temperature of the forum, and what influence you can have. Can you do more good by trying to join the cabal circles, with all the necessary diplomacy? Or can you do more good by speaking candidly in public?
>We're all humans
I'm just obeying orders please don't be mean to me :'( :'( :'( :'(
I'm just obeying orders please don't be mean to me :'( :'( :'( :'(
> It also doesn't mean that the proposal is "done" and the proposal authors won't appreciate constructive suggestions for improvement. Different proposals may be in different stages of their development, and early stage proposals are often extremely malleable.
It's important to note that this is, as of now, much less "malleable" due to it being implemented in Chromium[0]. Personally, it looks like it's just been implemented and then someone has thrown together a standard later.
The same person behind the specification has also published a testing suite[1] for the API, too. Pretty damning, if you ask me.
[0]: https://source.chromium.org/search?q=getEnvironmentIntegrity... [1]: https://rupertbenwiser.github.io/wei-wpt/
It's important to note that this is, as of now, much less "malleable" due to it being implemented in Chromium[0]. Personally, it looks like it's just been implemented and then someone has thrown together a standard later.
The same person behind the specification has also published a testing suite[1] for the API, too. Pretty damning, if you ask me.
[0]: https://source.chromium.org/search?q=getEnvironmentIntegrity... [1]: https://rupertbenwiser.github.io/wei-wpt/
For those like me unaware of the context here: https://www.theregister.com/2023/07/25/google_web_environmen...
Since this is here and there is a point made about discussing the technical merits of [0]... can someone explain to me how the WEI stuff isn't easily "faked" by scrapers and the like?
I could see this being used in a similar way to user agents (sometimes helpful when working on bugs and fixing them on minor platforms!), but I'm really struggling to see the overall value-add here.
I get the politics aspect of it (I think...), but what's the new technical thing being added here?
[0]: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
I could see this being used in a similar way to user agents (sometimes helpful when working on bugs and fixing them on minor platforms!), but I'm really struggling to see the overall value-add here.
I get the politics aspect of it (I think...), but what's the new technical thing being added here?
[0]: https://github.com/RupertBenWiser/Web-Environment-Integrity/...
I believe the idea is that an independent third party will cryptographically sign something to attest that the client is legit.
So you can't fake that unless you have the third party's private key.
If course the question is then, how does the attestation third party ensure you are sending it real information? I've not bothered to read the proposal because I don't care, but I suspect it will require client-side plugins/libraries etc snooping on what is going on kinda like an antivirus thing snoops on things going on.
So you can't fake that unless you have the third party's private key.
If course the question is then, how does the attestation third party ensure you are sending it real information? I've not bothered to read the proposal because I don't care, but I suspect it will require client-side plugins/libraries etc snooping on what is going on kinda like an antivirus thing snoops on things going on.
> how does the attestation third party ensure you are sending it real information?
The WEI standard does not prescribe this, as far as I can tell. One way to do this would be to use something like Secure Boot (broadly speaking), which can make "independent" measurements of what is being executed and sign that with a private key that never leaves (something like) a TPM.
The WEI standard does not prescribe this, as far as I can tell. One way to do this would be to use something like Secure Boot (broadly speaking), which can make "independent" measurements of what is being executed and sign that with a private key that never leaves (something like) a TPM.
There are aimbots for all modern games even though the developers have invested in anti-cheat
There is still one aimbot per human player. If you are faking clicks on opponents ads to exhaust their budget you would prefer to just send the http requests. If you have to spin up an emulator it will frustrate you and if you have to run a physical device with a touchscreen it will frustrate you further.
Incidentally, here's a new crowdsourced scheme for TF2 that even in prototype form has been addressing the issue far better than Valve's efforts:
I Pissed Off Every Cheater in TF2 (Data Breach Gone Wrong) | https://www.youtube.com/watch?v=LVgk5t64cRs
Creating a Third-party Client to Auto-kick Cheaters and Bots from TF2 (Part 1/3) | https://www.youtube.com/watch?v=EPsWjdkyoPo
Basically cheaters don't seem to want just a one off high like a classic troll out for havoc, they want a reputation of being better than they are for an extended ego trip. Their choice will soon be either restraining themselves to becoming very subtle, or keep having to make new accounts.
I Pissed Off Every Cheater in TF2 (Data Breach Gone Wrong) | https://www.youtube.com/watch?v=LVgk5t64cRs
Creating a Third-party Client to Auto-kick Cheaters and Bots from TF2 (Part 1/3) | https://www.youtube.com/watch?v=EPsWjdkyoPo
Basically cheaters don't seem to want just a one off high like a classic troll out for havoc, they want a reputation of being better than they are for an extended ego trip. Their choice will soon be either restraining themselves to becoming very subtle, or keep having to make new accounts.
Even if the client is legit someone can just use a web extention or the devtool protocol to navigate to pages and extract text.
I think the point is that the server won't send the content if attestation fails
So the data isn't there at all - it's not just hidden away behind some JavaScript
So the data isn't there at all - it's not just hidden away behind some JavaScript
I'm saying that extentions and developer tools still exist in browsers that will be attested.
[deleted]
I'm sorry for the Chrome devs to be on the receiving end of the shitstorm. I've met quite a few of them and I know they do care about the Web.
But I'm not sure if they realize, being on the inside of Google, just how much goodwill this company has lost on numerous botched UA sniffs, AMP, EME, manifest V3. We've had "we're listening, but we're doing it anyway" before.
But I'm not sure if they realize, being on the inside of Google, just how much goodwill this company has lost on numerous botched UA sniffs, AMP, EME, manifest V3. We've had "we're listening, but we're doing it anyway" before.
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?