There are a number of things to consider: *It's my device, and I have the right to do what I want to do with it. Not somebody else.*
While I am 100& supporting this statement, this ship has sailed a long time ago. Our friends @Google already control many things that especially influence the life cycle and functionality of PWAs. But that is a completely different discussion I am having on different channels. As to the topic here: We can implement integrity in different ways. IMHO the best way would be to not load failed resources at all. Kind like it is today with subresource integrity. Once the resource has been loaded, you may do whatever you want with it as there is no more integrity checking. M. On Wed, Jul 19, 2023 at 8:39 AM A. M. <a...@bitbox.sh> wrote: > This is literally 1984. Stop the war against general purpose computing. I > am not willing to give up privacy for added security. > > > I want to be forthright in saying that I have the same concerns. For > this reason, it is an explicit goal in the explainer to "Continue to allow > web browsers to browse the Web without attestation." > Here's the problem: Once it's implemented, what will stop websites to > block users who disable it? You can't use most banking apps (or even the > McDonalds app, Snapchat, ...) on phones because they require passing > SafetyNet. It's fundamentally the same thing. > > It's *my *device, and *I* have the right to do what I want to do with it. > Not somebody else. > Michaela Merz schrieb am Mittwoch, 19. Juli 2023 um 03:29:39 UTC+2: > >> It would be my suggestion that a "broken" integrity should result in a >> browser warning (like an invalid TSL certificate) allowing the user to >> continue if he/she so chooses. That would allow "twiddling" while also >> giving a normal user an amount of security that nobody else has "twiddled" >> with the code. >> >> m. >> >> >> On Tue, Jul 18, 2023 at 4:11 PM Morgaine (de la faye) <rek...@gmail.com> >> wrote: >> >>> How does this feature interact with users trying to use DevTools to >>> understand how a site works ? There's notably not really any discussion of >>> what an attestable environment is. This specification seems entirely open >>> ended for how locked down a system might be or what might be permitted. >>> >>> It seems all too likely that anyone using DevTools to look at or twiddle >>> with a site has already broken the "Environment Integrity" seal. Is that >>> the case? How do we maintain RFC 8890 in the face of this open ended >>> specification which seems to have no limits on what it can do to restrict >>> users? >>> On Monday, May 8, 2023 at 11:30:30 AM UTC-4 Ben Wiser wrote: >>> >>>> Contact emails >>>> >>>> serg...@chromium.org, pb...@chromium.org, ryan...@google.com, >>>> b...@chromium.org, erict...@chromium.org >>>> 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 >>> blink-dev+...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/baef87c2-92ee-4175-8b04-9d229a4043b9n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/baef87c2-92ee-4175-8b04-9d229a4043b9n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 > blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6158a8cb-1de4-4b38-9a5b-068d43dc1054n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6158a8cb-1de4-4b38-9a5b-068d43dc1054n%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKDb%2By6%2BP_u9Dnmxju_Xv%3DA6zQ6skcsnV5eCMsaxP8%3Dja8A63Q%40mail.gmail.com.
