undefined | Better HN

0 pointsdanShumway2y ago0 comments

Respectfully, that response is kind of a roller-coaster. It's hard to know where to even begin.

> device controlled [...] unmodifiable [...] nonaproved hardware

Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing. Conflating device control to browser restrictions is also nonsensical given that the whole point of the web is that sites are browser neutral, and (again with exception of user-hostile features like DRM) browser forks are largely undetectable. Building a website that reliably blocks Linux is hard, borderline impossible. Even blocking scrapers is a losing battle, with a bit of work Headless Chromium is virtually undetectable (which of course it is, because if it was easy to detect headless browsers nobody would be arguing that "trusted" environments were necessary to stop scrapers and headless access). The user agent string is user controlled and I can easily set it to anything I'd like. A user agent string is not even remotely comparable to attestation. The web is not the way that HTML renders, the web is the platform, not just HTML.

> Sites can already detect adblocking without attestation. There is no evidence that the precense of an adblocker will be a signal to whether an environment is trustworthy. That is not the purpose of the API.

Sites can't reliably detect adblocking without lots of work, there's not an easy API for that. And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking, look at native apps on mobile platforms that support attestation. Native apps like Netflix already refuse to run on rooted devices. Their reason for that is to lock down possible circumvention of the client or redirection of the video stream. It's a content decision made to block users from altering the client/content (ie, exactly what adblockers do).

Attestation for native applications has never been a rare thing that only banks used. And also, heck banks, banks don't need attestation. I should be able to load my banking app on a rooted Android device. Banks are not an excuse to take away that ability away from me.

What the "purpose" of the API is doesn't really matter. How it will be used matters. Device attestation is regularly abused on Android devices, there is no evidence that this will be different. But like I said, maybe the people proposing it don't have bad intentions, maybe they're just naive. Either way the outcome is going to be the same.

> No, it won't. You just have to use a different API.

uBlock Origin already objectively runs worse on Chrome than Firefox. Gorhill has stated numerous times that Manifest V3 will make this worse. Also I'm familiar with Manifest V3's API differences between Firefox/Chrome's implementation, and I agree with him, Chrome's Manifest V3 API is worse for adblockers.

This is denialism, Manifest V3 makes adblockers less effective.

> Look at the reponse to FLOC. Despite increasing user's privacy many people forgot upset because they greedily want the web to cater to only them and not to people who rely on advertising

And there it is, makes me feel like clarifying the above points was a waste of time. Objection to this is greedy because we've forgotten about the people who rely on advertising.

I mean, come on. You can't even consistently keep up the charade of arguing that this isn't about adblockers for two comments before accidentally slipping into arguments that the advertisers are the real victims. When you write that sentence, you have to on some level realize that it's not going to make people trust the proposal more.

> Similarly with Web DRM people panicked because they didn't want DRM because they only care about themselves and do not care about people who want their content to be protected.

This sentence is also just a great way to convince people you're sincere when you argue that a proposal isn't meant to lock down devices or introduce HTML-level DRM -- no notes. ;)

----

I will give you this: If for some inexplicable reason you've come out of Web DRM, and Manifest V3, and FLOC, and Topics, and Web Audio changes, and a lack of mobile extension support, and AMP, and First-Party Sets, and the Conversion Measurement API, and on and on -- and somehow you believe those proposals were all good and worked out great and nobody had anything to complain about, then I buy that you would probably also look at this proposal and wonder why people were getting worked up.

The issue is that I have no idea how on earth anyone paying attention to the direction of the web could come to the conclusion that those proposals didn't have problems. But if somehow you've magically been able to do that, then I understand why the pushback to this proposal probably seems weird to you.

0 comments

3 comments · 1 top-level

charcircuit2y ago· 2 in thread

>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing

You did it first. Attestation has nothing to do with extentions.

>Building a website that reliably blocks Linux is hard, borderline impossible

With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.

>And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking

Please share it.

>It's a content decision made to block users from altering the client/content (ie, exactly what adblockers do).

The difference is that web browsers allow extentions, but the Netflix app doesn't.

>uBlock Origin already objectively runs worse on Chrome than Firefox

I use it just fine on Chrome and do not see any ads.

>Chrome's Manifest V3 API is worse for adblockers.

It has the same API for blocking ads. The API for blocking network requests is what changed.

>You can't even consistently keep up the charade of arguing that this isn't about adblockers for two comments before accidentally slipping into arguments that the advertisers are the real victims.

FLOC is about trying to get advertisers to stop invading people's privacy. You shouldn't be surprised that advertisers are a stakeholder when talking about FLOC. Advertisers are as important stakeholder in the web in general. In regards to attestation there are more stakeholders than just users and advertisers since security is important to almost any type of service on the internet.

>I have no idea how on earth anyone paying attention to the direction of the web could come to the conclusion that those proposals didn't have problems

The direction is not going away from web extentions and I don't see anything going after adblock extentions.

danShumwayOP2y ago

>Conflating serverside generated code to native app restrictions is nonsensical, they are not the same thing > You did it first. Attestation has nothing to do with extentions.

First of all, extensions are not serverside code, so... no, that doesn't make any sense. Second of all, attestation has a lot to do with extensions because extensions are based on browser functionality, and attestation impacts which software you can run. In this case, attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs.

And attestation has even more to do with extensions when extended to websites than it normally would because if the point of this is to established "trusted" environments, then arbitrary extension access to a web page means the environment is not trusted. If you allow arbitrary extension access, you can't provide guarantees about whether someone is human or not -- extension APIs allow for automation and scraping and ad fraud. And blocking that behavior is explicitly one of the use-cases listed in this proposal for the integrity API.

If this doesn't block extensions, then it's not a useful proposal for blocking bots. Quite literally every single use-case that this proposal lists are impossible if extensions are not restricted. Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions. A "trusted environment" the way the proposal describes it can not have arbitrary extension access because extensions can do all of that stuff; from posting automated content to fraudulently clicking on ads to cheating at online games to stealing your bank password.

> With attestation doesn't reveal what OS you are using, so it owned still be impossible to reliably block Linux.

Do you genuinely think that an Open Linux environment is going to support attestation? We're having a hard enough time getting Passkey to support Linux, there is zero chance that Arch Linux becomes a trusted attestation provider for the Web Environment Integrity API.

And if it did, this whole proposal would be useless, because I'd be able to use Headless Chromium on Arch Linux and just have Arch Linux say that my computing environment was secure. There is no definition of "trusted computing environment" for a website provider that doesn't involve blocking access to arbitrary user-controlled code execution at the OS and browser level.

Because if you couldn't block that access, you wouldn't have any security guarantees. The entire premise falls apart if fully user-controlled environments are supported. It would be a useless proposal.

> And there is a ton of evidence that attestation will be used for DRM and to prevent adblocking > Please share it.

https://developer.android.com/google/play/integrity -- please do any amount of research into how this has played out.

> uBlock Origin already objectively runs worse on Chrome than Firefox > I use it just fine on Chrome and do not see any ads.

https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... -- this is also not very difficult to look up, I kind of feel like you should have been able to find this link yourself.

> FLOC is [another long explanation of why advertisers are the victim and FLOC is actually making the web more private]

I have to say again, I don't know if you expect this to sway anyone reading these comments, but it's not going to. No one is going to read that paragraph and think, "you know what, this person probably does care about adblockers and probably is really committed to making sure they're not harmed."

charcircuit2y ago

>attestation means websites can check to see if you're running modified or forked browsers that might allow for broader extension APIs.

It does not tell you what browser the user is using. Websites can not block a specific browser.

>Blocking ad fraud, blocking bots, blocking malware from a banking site, and blocking cheating in web games -- all of that requires blocking extensions

    How does this affect browser modifications and extensions?
    Web Environment Integrity attests the legitimacy of the underlying hardware and software stack, it does not restrict the indicated application’s functionality: E.g. if the browser allows extensions, the user may use extensions; if a browser is modified, the modified browser can still request Web Environment Integrity attestation.

It's about reducing the rate of those things.

>Do you genuinely think that an Open Linux environment is going to support attestation?

When Linux distributions start to actually care about security yes I do see plenty.

>Play Integrity

Play Integrity covers both attesting to if the system is in a secure state and if the app you are running is from the play store. This proposal only has an equivalent for the former.

>this is also not very difficult to look up

Chrome has worked on CNAME stuff since that was written and most of it does not really matter to most people.

>another long explanation of why advertisers are the victim and FLOC is actually making the web more private

Advertisers aren't the victim in this situation. It's the users who are losing privacy due to cross site tracking.

1 more reply

j / k navigate · click thread line to collapse