61–70 of 114 posts
Blog post author here. 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 sta…
> 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 clear…
> 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 clear…
[flagged]
hope this helps :)
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.
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…
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".
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 po…
"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
Earlier quoted context omitted.
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 plugin…
There are aimbots for all modern games even though the developers have invested in anti-cheat
Earlier quoted context omitted.
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.
That's as clear as day, they won't let you view the page with ad blocking.
Blog post author here. 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 sta…
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 it…
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_...
Earlier quoted context omitted.
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…
> 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…
This proposal is so early stage that it hasn't passed the "personal repo"
phase just yet.