|
Top-level
 @rcombs FWIW, I've worked with those people (Borbala was my tech lead, then manager for ~2.5 years), and I genuinely believe they're trying to do the right thing here. The bot problem on the internet is not well understood by the average user/developer, mostly because that's an area where "obscurity" is still part of the best strategies the defenders have, and also because the bad actors focus their efforts on just a few targets (Google, Meta, Twitter, etc.). 21 comments
@delroth you're equating bots with, what, bruteforce attempts on user passwords? which is an extremely mitigable problem that's entirely solved by passkey usage @rcombs in general: there are 10-100s active full-time criminal groups targeting Google users at all times. Some are interested in stealing SSNs and passport photos from gmail. Some are interested in stolen credit cards (via reselling tradeable in-game items in Play Store games, for example). Some deploy cryptolockers on Google Drive. Often they either have credentials, phish them, or have session tokens stolen by malware on device. Passkey/2FA helps, but doesn't prevent the latter. @rcombs Google isn't just fighting that on one front, they've been strongly pushing for 2FA for years. They were the first to deploy Security Keys for a reason. There's been many efforts to try and bind session tokens to devices too. Example: Channel ID. Unfortunately not successful. The "defense front" you're seeing is trying to detect suspicious actions coming from non legitimate devices. If someone gmail-searches "SSN" and you can detect it's not a real browser, you can issue a challenge. @rcombs this isn't really the appropriate format to try and summarize 3 years of learning about this in the field, working with probably some of the foremost experts in the field. I also likely will get into NDA things pretty quickly with more details. Those experts are people I recognize in the list of authors of the proposal. They're people that have spent their whole career working on protecting users from data theft / impersonation. I personally trust that they have done their homework. @rcombs another angle: do you think those people don't know how bad such a proposal looks, especially coming from Google? Look at the list of non-goals, the number of counter-measures they propose to avoid this being too abusable, etc. They clearly understand your viewpoint as well, to some extent. And yet they still thought it would be a good move to publish this proposal. Do you think they would have done so if "this ain't gonna solve that case" (or rather: "help", you can't "solve" abuse)?   @ariadne @rcombs I think that's always a reasonable worry (though tbf I do personally think providers should have a choice of how they charge for their content). But note that the proposal in question explicitly states as a non-goal "Enforce or interfere with browser functionality, including plugins and extensions." @delroth @ariadne @rcombs That may be a "non-goal" as far as the spec is concerned, but after reading the explainer it's clear to me that none of the other goals of the spec can be achieved without also making that possible. And on the commercial internet, the incentives for both attesters and site operators point towards doing that. @carcosa if that's the case (I haven't done a full technical analysis of what they propose): I think that's a fair criticism, and I don't think a spec proposal should be accepted when it's not self-consistent. I think that's significantly more nuanced and actionable commentary than "DRM bad", and I presume that this is part of what the spec review process would go into (W3C/Whatwg/... have privacy experts reviewing these things, and they seem to already have been engaged). @delroth Yeah. Specifically, look at the discussions of the holdback mechanism, which is the one part that is supposed to prevent website operators from discriminating against unattestable browsers. Stakeholders in the security business are arguing that it's not acceptable to have holdbacks at all; I'm arguing that if implemented, holdbacks will erode over time until attestation can be used to discriminate on the basis of browser/plugins/etc. @ariadne@social.treehouse.systems @delroth@mastodon.delroth.net @rcombs@social.treehouse.systems |
Gregory's Server
@rcombs the proposal does talk about the DRM aspects of this, and tries to propose solutions that mitigate that issue. I don't know whether they're appropriate solutions or not, whether they go far enough or not, etc. I think that would be a healthy debate.
Saying "user agents shouldn't do that" is basically saying it's fine for millions of users every month to get their bank accounts stolen, their personal information sold on black markets, etc. -- unless you have a magic solution.