this message got me to write down my thoughts and a little case study of the last year's Big Mac exploit (not an exaggeration). https://liberda.nl/weblog/trust-no-client/
On Wednesday, 26 July 2023 at 01:31:25 UTC+2 Tom Jones wrote: > Perhaps it is a good thing for user choice to have a browser that is fully > open to any use and allows anonymous user actions. > > The result of such open-ness is that an entire series of services that > need to trust the client(used in the oauth sense of the word) are not > available to web apps. > > Consider the effort in IETF Remove Attestation Services (RATS > https://datatracker.ietf.org/wg/rats/about/) to get web trusted client > apps. Without knowing the operating environment (ie the sandbox) such a > statement loses most of its value. > > I have recently worked on a fork of Chromium that is designed to have this > functionality and on Native Wallet apps to get it. The lack of this > functionality in Chrome will drive developers away from Chrome and fragment > the user experience. We already have the problem of directing users away > from Chrome to a secure wallet and being unable to bring the original user > session back to Chrome. Of course Google and Apple get to solve this > problem with their own wallets, but that will not fly in Europe and now the > US DHS is asking for solutions that are more open as well. > > Something needs to change. If this solution is not available, then the > change will be outside the browser. ..tom > > > On Sun, Jul 23, 2023 at 4:02 PM Dana Jansens <[email protected]> wrote: > >> There's been a lot of strongly worded negative feedback for this proposal >> in the Github, and I don't agree with how that feedback was delivered but I >> do agree that this proposal if followed would not be good for the web. >> >> The proposal talks about trust, but the server does not need to trust the >> client. Like palmer said, they can never trust the client, this doesn't >> allow them to trust the client in a way that could be considered a security >> boundary. That is a fundamental design choice of client-server with open >> user agents, in place of closed apps/walled gardens. This is an intentional >> property of the web. >> >> But this proposal provides a mechanism for web sites to force their >> ideals and preferences onto user agents, which takes away user autonomy and >> choice, and damages the trust held by Chromium as the dominant user agent >> today. Let's push the world to be more open, to give more user control, not >> more controlled and closed. >> >> Dana >> >> On Thursday, July 20, 2023 at 1:41:45 PM UTC-4 Reilly Grant wrote: >> >> Michaela, I think you are misunderstanding this proposal. This is not a >> proposal for a site to prove its integrity to the user. It is a proposal >> for the user agent to prove its integrity to the site, and that it is >> acting on behalf of a real user. These are two largely independent >> problems. I recommend looking at Isolated Web Apps >> <https://github.com/WICG/isolated-web-apps>, which attempt to solve >> exactly the problem you're discussing. >> >> On Thu, Jul 20, 2023 at 8:18 AM 'Michaela Merz' via blink-dev < >> [email protected]> wrote: >> >> Thanks @Chris Palmer for your input. Nobody is more opposed to DRM than I >> am. Even today I refuse to load DRM extensions into the browser. I think >> that DRM is wrong and the open web is the way to go. >> >> But providing provenance and integrity to a resource is not DRM. TLS is >> not DRM. If you hit a page with an invalid TLS certificate, you are free to >> continue. If the power to be would decide to NOT allow us to continue to >> sites without a valid TLS certificate, you'll find me on the barricades >> right along with you. >> >> Browsers already include a protection mechanism called "Subresource >> Integrity" (SIR) . If the provided resource doesn't match the hash, the >> browser refuses to load the resource. Together with "content security >> policy" we can already create hardened web resources. But we're missing one >> crucial element: If the web site has been modified on the server. If a >> malicious attempt to modify a web environment is successful right at the >> source, we (and our users) have no way to protect us and our users. >> >> That's why I think it is important to extend the SRI with a "master key" >> or certificate that can not be recreated without the knowledge of the >> author of the web site. >> >> We can and must discuss the details of such a mechanism of course. I am >> with you and don't want DRM through the back door. But I think it's crucial >> for the web environment's credibility to have tools that can be used to >> protect the integrity of the environment. >> >> m. >> >> >> On Thu, Jul 20, 2023 at 7:05 AM Chris Palmer <[email protected]> wrote: >> >> Speaking as a recent former Chromie who wants you to succeed: retract >> this proposal. >> >> * The web is *the* open, mainstream application platform. The world >> really, really needs it to stay that way. >> >> * Whatever goals publishers might think this serves (although it >> doesn't), extensions and Dev Tools (and other debuggers) neutralize it. >> Extensions and Dev Tools are incalculably valuable and not really >> negotiable. So if something has to give, it's DRM. >> >> * The document claims WEI won't directly break content blockers, >> accessibility aids, et c. But: (a) this will be used as part of an argument >> to not bring extensions to Chrome for Android; and (b) assume/realize that >> publishers will start rejecting clients that support extensions. Chrome for >> mobile platforms already doesn't support extensions, and mobile is the >> largest platform class. So publishers might even have a decent chance of >> getting away with such a restriction. >> >> * DRM will always be cracked and worked around, but that doesn't mean >> that implementing this will be harmless. DRM still shuts out legitimate use >> cases (accessibility comes foremost to mind, but not solely), even when it >> is broken. Everybody loses. >> >> * DRM misaligns incentives: the customer is now the adversary. This is a >> losing move, both from a business perspective and from a technical security >> engineering perspective. (Do you want an adversarial relationship with >> security researchers? No, you do not.) WEI enables publishers to play a >> losing game, not a winning one. >> >> * In ideal circumstances, WEI would be at best a marginal, probabilistic, >> lossy 'security' mechanism. (Defenders must always assume that any given >> client is perfectly 'legitimate' but 'malicious'. For example, Amazon >> Mechanical Turk is cheap.) Holdbacks nullify even that marginal benefit, >> while still not effectively stopping the lockout of particular UAs and yet >> not effectively upholding any IP-maximal goals. >> >> * Chromium has a lot of credibility in safety engineering circles. Don't >> spend it on this. >> >> On Monday, May 8, 2023 at 8:30:30 AM UTC-7 [email protected] wrote: >> >> Contact emails >> >> [email protected], [email protected], [email protected], >> [email protected], [email protected] >> Explainer >> >> >> https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md >> Specification >> >> We do not have a specification yet, however we expect to publish in the >> near future both the considered implementation options for the web layer in >> an initial spec, which we suspect are not very controversial, and an >> explanation of our approach for issuing tokens, which we expect will spark >> more public discussion, but is not directly a web platform component. We >> are gathering community feedback through the explainer before we actively >> develop the specification. >> TAG Review >> >> Not filed yet. >> Blink component >> >> Blink>Identity >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity> >> Summary >> >> This is a new JavaScript API that lets web developers retrieve a token to >> attest to the integrity of the web environment. This can be sent to >> websites’ web servers to verify that the environment the web page is >> running on is trusted by the attester. The web server can use asymmetric >> cryptography to verify that the token has not been tampered with. This >> feature relies on platform level attesters (in most cases from the >> operating system). >> >> This project was discussed in the W3C Anti-Fraud Community Group on April >> 28th, and we look forward to more conversations in W3C forums in the >> future. In the meantime, we welcome feedback on the explainer >> <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md> >> . >> Motivation >> >> This is beneficial for anti-fraud measures. Websites commonly use >> fingerprinting techniques to try to verify that a real human is using a >> real device. We intend to introduce this feature to offer an adversarially >> robust and long-term sustainable anti-abuse solution while still protecting >> users’ privacy. >> Initial public proposal >> >> https://github.com/antifraudcg/proposals/issues/8 >> Risks >> >> Interoperability and Compatibility >> >> We are currently working on the explainer and specification and are >> working with the Anti-Fraud Community Group to work towards consensus >> across the web community. The “attester” is platform specific so this >> feature needs to be included on a per platform basis. We are initially >> targeting mobile Chrome and WebView. >> >> Ergonomics >> >> See “How can I use web environment integrity? >> <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#how-can-i-use-web-environment-integrity>” >> >> in the explainer. Note that we are actively looking for input from the >> anti-fraud community and may update the API shape based on this. We also >> expect developers to use this API through aggregated analysis of the >> attestation signals. >> >> Security >> >> See the “Challenges and threats to address >> <https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md#challenges-and-threats-to-address>” >> >> section of the explainer to see our current considerations. >> >> Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)? >> >> We initially support this only for Android platforms (Android, and >> Android WebView). This feature requires an attester backed by the target >> platform so it will require active integration per platform. >> >> Is this feature fully tested by web-platform-tests >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md&data=04%7C01%7CAmanda.Baker%40microsoft.com%7C84c5e8a01bc1471e348f08d7c6b940f0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637196371372857279%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=M79bBRPkECK4YmZwW1JAdcqHCofWo6qpz3TFFwnvqB8%3D&reserved=0> >> ? >> >> Web platform tests will be added as part of this work as part of the >> prototyping. We will then feed those tests back into the specification. >> >> Requires code in //chrome? >> >> True >> >> Feature flag (until launch) >> >> --enable-features=WebEnvironmentIntegrity >> >> Link to entry on the Chrome Platform Status >> >> https://chromestatus.com/feature/5796524191121408 >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "blink-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/a/chromium.org/d/topic/blink-dev/Ux5h_kGO22g/unsubscribe >> . >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28a637ff-682c-4a38-b3a9-f2bfa2b48c44n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/28a637ff-682c-4a38-b3a9-f2bfa2b48c44n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7gDGdiWTKR832P7m2hH0p1VtxXqvnBxwYnAZ0AQjo4jQ%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By7gDGdiWTKR832P7m2hH0p1VtxXqvnBxwYnAZ0AQjo4jQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5f5a252-a0fc-4c37-8ae8-9a460d20373an%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/417c4dc9-68c7-4379-8a5e-1c603d594ef2n%40chromium.org.
