Privacy by design with browser-managed E2E encryption and Fenced Frames

[Minigugus]

Offline-only storage

TLDR Add built-in end-to-end encryption support into web browsers, and prevent first-party from leaking data by denying network access once enabled. Also, allow users to choose where their encrypted data should be stored (not an issue for the web site publisher as it won't be able to read data anyway, because of E2E encryption)

Here is a summarized description of traditional architecture for web apps:

flowchart LR;
  subgraph P ["Back-end (Publisher's servers)"]
    SPB("Web app");
  end

  subgraph C ["Front-end (Consumer device)"]
    SC(User);
    subgraph BB ["Web browser"]
      SPF("Web app");
      B("Storage API");
    end
  end

  style BB fill:darkblue,stroke-width:0px;

  SC-->|Request/Update|SPF;
  SPF-->|Respond/Inform|SC;
  SPF-.->|Request/Update|SPB;
  SPB--->|Front-end code|SPF;
  SPB-.->|Respond/Inform|SPF;
  SPF-->|Process|SPF;
  SPB-.->|Process|SPB;
  SPF-->|"Write"|B;
  B-->|"Read"|SPF;

Loading

This architecture works great, except for privacy: the web app publisher owns users data (or at least this architecture
requires the web app publisher to have full access to users data, in order for the web app to work properly). This is an
issue, for users, but also for the web app publisher:

• Costs increase along with the number of users
• Managing user data mean additional development, maintenance and storage costs (authentication needed, requiring a
  database for users account, and so on...)
• Users pay the price for weak server-side security (e.g. database leaks)

Actually, with this architecture, the web app publisher doesn't really have the choice to own user data. The modern web
offers solutions to theses issues (e.g. PWAs), but that's not enough for web apps in production that could leverage
browser storage as main storage provider (e.g. single player games, IDEs, authenticators/passwords managers apps):

• The security/privacy risk is still present: compromised front-end code can still intercept user data (even with E2E
  encrypted apps: listening to DOM changes is enough)
• Browser storage seams still considered more like a cookie container than a reliable application storage:
  • Users may accidentally and permanently lose their data if they clear their cookies in bulk for instance
  • No data mobility/backup: each browser instance has its own storage state, saved locally. Authentication is then
    the only way for users to access their data on multiple device.

Theses are true blockers for many web apps that could work entirely without a back-end. A good example of such apps are
single-player games, or even authenticator/passwords managers apps: web app's publisher must not be able to access
highly sensitive user data, and once loaded, the app doesn't need a server to provide credentials (OTP for instance), then
the best would be to only store user data client-side only, but that's risky: the browser may not encrypt browser's
storage, and even worse, the user might accidentally clean application storage permanently, which is extremely dangerous
for OTP. As a result, authenticator/passwords managers apps can't be built as web apps, or at least required E2E
encryption + authentication, which is costly for the publisher, and don't prevent all security risks (on compromised
update of the front-end code could still leak sensitive user data). As explained below, the solution proposed here try
to address these issues with a small architecture change for web apps that opt-in.

Proposed solution: External storage provider + Fenced frames

Offer to web apps a way for storing all data client-side rather than server-side, but with the trade-off of loosing
network access (to prevent data leaks):

flowchart RL;
  subgraph C ["Front-end (Consumer device)"]
    SC(User);
    subgraph BB ["Web browser"]
      B("Storage API");
      SPF("Web app");
    end
  end

  subgraph S ["Storage provider environment"]
    SSP("Storage provider");
  end

  subgraph P ["Back-end (Publisher's servers)"]
    SPB("Web app");
  end

  style BB fill:darkblue,stroke-width:0px;
  style SSP fill:green,stroke-width:0px;

  SC-->|Request/Update|SPF;
  SPF-->|Respond/Inform|SC;
  SPF-->|"Write"|B;
  B-->|"Read"|SPF;
  B==>|"Persist"|SSP;
  SSP==>|"Retrieve"|B;
  SPB--->|Front-end code|SPF;
  SPB-.->|Inform|SPF;
  SPF-->|Process|SPF;
  SPF-.->|Request/Update|SPB;

  linkStyle 4 stroke:green,stroke-width:4px;
  linkStyle 5 stroke:green,stroke-width:4px;
  linkStyle 9 stroke:red,stroke-width:4px;

Loading

As shown above, the proposed solution consist of 2 parts:

• (in 🟢) Introduce an external storage provider, that the browser use to synchronize application data with.
  The external part is important: it let the user choose where their data should be stored: on disk storage (probably
  the default), cloud-based storage (using an account, for multi-device synchronization), or anything else the community
  can provide (let web extensions endorse the role of storage provider for instance). Also, for privacy reasons,
  browsers should encrypt user data before passing them to the storage provider, so that providers don't have access to
  what's stored, not even web apps origins (i.e. no need for the user to trust the storage provider; data can even be
  stored publicly (e.g. IPFS could work)). Follow points 2.8 and 2.11 of the W3C TAG Ethical Web Principles
  .
• (in 🔴) Disable communication with first- and third-parties (like Fenced frames but on the top level
  frame too for instance). This is the final peace to add Privacy by design to all compatible web apps: this change
  ensure that even the web app publisher won't be able to access user data. Web app can still opt-out at anytime, but
  will lose access to what they stored then (browsers won't delete data thought, they'll just stay in the storage
  provider). Follow points 2.5 and 2.8 of the W3C TAG Ethical Web Principles.

As a result, web apps using the offline-only storage will always respect user privacy. Browsers should then inform the
user about that positive point, so that web apps get "rewarded" with happier users (much like with the green lock when
websites preferred HTTPS over HTTP). That way, the web should tend to become safer at the same time.

For quite obvious reasons, the proposed solution have to be opt-in for web apps providers, or it would break all the
web. The "how" is still to be discussed thought.

Pros

• Privacy
  • Users now owns their data on compatible websites. Organizations could store their members' data on premise.
  • Users only have to trust their browsers (no more the web app publisher (no data access), or the storage provider (
    encrypted data, no even possible to infer what origin the data is coming from)): since browsers are already
    trusted for their sandboxing capabilities, and that most implementation are open source, it seems better that
    way (only having to trust the browser)
• Security
  • Fix a whole class of attacks: even the web app owner wouldn't be able to access user data! The only weak point
    left is the browser itself, but they proved to be very fast to deliver security fixes, often faster than web apps
    providers
  • 🔥 Fix another class of attacks: since even web app publishers don't have access to user data, there is
    nothing to leak! Moreover, since each user store its own data, it becomes impossible to leak millions of users at
    once (attackers would have to infect devices of each user). Finally, since storage providers only see encrypted
    data, even storage providers leaks are not an issue
• Freedom
  • Web app publishers are no more charged with user data storage, related code maintenance and legislation: it
    becomes possible for anyone to build a web app that's used by millions of users at no costs other than these
    related to web app's development (especially with SXGs). This point can
    really benefit to independent developers and small businesses, that generally can't afford good security measures
    for user data protection.
• Experience
  • All browsers features remain available
  • Users gain more control over web apps they use: they could select which "application profile" to recover, on a
    per-origin basis
  • Authentication is often no more required, since web apps no more have to deal with user data management, resulting
    in improved user experience
  • Developers experience is improved too: less boilerplate code to maintain (authentication, communication with
    back-end code for user data retrieval)
  • Many browsers' features require user interaction (e.g. camera/mic, geo-location, reading filesystem, etc.),
    primarily because of the sensitivity of data that to the web app could leak, potentially to any server on the
    internet. With communication disallowed, such risk no more exists, then maybe some features access could be
    relaxed, or at least the user could choose which feature to enable by default on web apps supporting the solution
    described here. Also, this new architecture give access to new potential features, e.g. allow reading third-party
    and/or unpartitioned storage
• Analytics/Advertising
  • Advertising is still possible, especially with upcoming proposals like TURTLE DOVE
  • Analytics are still possible, but only the user would be able to see them (and if web apps providers really need
    analytics, maybe some proposals could be requested too I guess)
• Compatibility
  • Communication with external storage providers could be polyfilled with web extensions, so that web apps relying on
    offline-only storage could still work on older browsers, without the privacy guaranties thought, but it's up to
    the user to acknowledge the risks or not.
• Web's future
  • Whilst offline-only storage restrict web apps capabilities, it gives new privacy-first evolution perspectives for
    future proposals (e.g. privacy-respectful multi-users communication, offline cross-origin storage access, ...)
  • The web is built around decentralization, an aspect that offline-only storage contribute to
• Environment
  • No network communication mean reduced environmental footprint
  • Users can choose where their data are stored, so they can reduce their environmental footprint by selecting a
    greener storage provider (avoiding cloud-based one for instance)

Cons

• Security
  • A new threat model emerge, where web apps may leak data via QR codes, file system access, and so on. These threats
    already exists, but they risk to become more intrusive than before. Anyway, web apps already get flagged as
    malicious when they try to harm users so mitigation already available.
• Analytics
  • Web app publishers may not like not being able to get analytics, especially since they won't be able to detect
    cases where the app breaks because of outdated user data. However, Service Workers' cache have a similar issue
    that developers seams to handle quite well globally, so it's more a web app design issue. Also, nothing prevent
    the web app publisher to stay on the traditional model, that's the trade-off to pay to enjoy the architecture
    proposed here.
• Adoption (by publishers)
  • Not all web apps can be converted to this architecture (e.g. banking apps, multi-players games), but future
    proposals may fix that, still in a privacy by design manner. Anyway, at least web apps who can, could.
  • All the web is built around web servers, then a lot of tools become useless. However, as explained before, not all
    web apps are compatible, and servers to servers, semantic web, and so on still need these tools
  • Developers are not used to design web apps without a web server accessible, it may take some time for the
    environment to adapt. Yet, it's not impossible as PWAs are already asked to work at least partially offline. Also,
    incoming communications are still allowed, so real-time user experience might still be possible (
    see Implementation details below for more details)

Implementation details

While this document is entitled "Offline-only", not all requests are expected to be blocked: actually, here, the meaning
of "offline-only" is more "side-effect free", i.e. that can't leak user data content. For instance, requests resulting
of a user navigation are side effect free, because the server can't infer anything about the user data content (assuming
the URL wasn't generated using user data - the anchor (<a>) case is still to be discussed thought). On the other side,
it's not possible for the web browser to know which fetch('http(s)://...') requests are side effect free, so they
should be blocked. JS-triggered requests may still be allowed on some cases thought, for instance with prefetched SXG,
but it's still to be discussed. Furthermore, note that readonly communication is still allowed while having user data
access (e.g. via postMessage (with SharedArrayBuffer disallowed), or reading Unpartitionned Storage).

Depending on the feasibility, it might be possible to allow web apps to work in both trusted (user data access,
communication restrictions) and untrusted (no user data access, no communication restriction) modes, at the same time:
for instance, the service worker might be running in an untrusted context and the main page in a trusted one. The
service worker would be able to send messages via postMessage to the main page when a push notification is received
for instance.

Concerning how a web app request trusted mode, multiple solutions are available for discussion:

• Via a HTTP response header
  • + simple, consistent with CSP
  • + (probably) simpler to implement
  • - limited, no dynamic loading possible
• Via a one-way switch API (e.g. navigator.offlineStorage.enable()):
  • + simple, powerful, consistent with Service Workers
  • + supports dynamic loading (do fetch requests, then call enable())
  • + supports location.reload() to leave the trusted context without leak
  • + supports live updates (e.g. spawn a web worker that manage a web socket connection to feed the main page
    via postMessage())
  • - (probably) harder to implement (active connections have to be closed, SharedArrayBuffers access invalidated)
• (other solutions to discuss)

Offline-only storage could work in private browsing, since no user data would leave the browser anyway.

Link with Fenced Frames

The proposed feature could work like how Fenced Frames' read-only mode works. The main difference, however, is that a web app should be able to self-enter isolation mode (with some API), i.e. could work on top-level frames. This is important to allow browsers to notify the user that the displayed web page now operate privatly (good for web site reputation), and also to avoid top-level web documents to display a sole Fenced Frame HTML element when they want to use privacy-restricted APIs.

Other points to discuss:

• Same origin tabs communication
  • Does trusted mode apply to all tabs of the same origin, or per tab?
    • "All tabs" seems to add complexity to web apps' developers, and maybe to browsers' implementations too
  • Where to place the Service Worker?
    • Could be useful to have the worker intercepting requests in trusted mode, but what to do if others tabs are
      in untrusted mode? 1 Service Worker per mode, or only one in untrusted for simplicity?
  • Allow communication between same origin tabs in trusted mode?
• Allow communication between cross-origin tabs in trusted mode?
  • Could be useful for some apps (e.g. analytics apps) but could interfere with existing browser security measures
• New storage API or current storage (e.g. Local Storage, Indexed DB, ...) synchronization?
  • The Storage Access API could be a good candidate (e.g. adding a parameter for disabling outgoing communications)
• Multi-devices synchronization (sharing the same storage provider for instance)?
  • Can be handled by good design decision if a new storage API is preferred
  • Even without real-time synchronization, conflicts would happen anyway, so it's still a point to discuss
• Web apps can still manipulate the user to leak their data (e.g. with a QR code), is it an issue?
  • I guess no: actually, it really depends on whether the first-party care about users' privacy or not, which seams
    to be often the case as of today. Then, at least at the beginning, trusting web apps might be enough (not all
    apps' data are critical), as long as we keep an eye on how the web evolves.

Conclusion

The suggested feature is ambitious, there are some implementation challenges to overcome, yet implications for security,
privacy and web's future are worth a look. Not all web apps can use the proposed storage, but at least some could,
empowering users by letting them deal with their data as they which. Anyway, I hope this document could contribute to
W3C privacy goals for the web.

Related

• TURTLEDOVE: same idea (let the browser own application state access) but for
  advertising only and without DOM access
• Fenced Frames: mostly how communication restrictions should apply
• Privacy-Safe Storage API #28: original idea, but not attractive enough (was too restrictive on implementation details and did not solve the
  data mobility issue)
• W3C Privacy Principles: W3C guidelines about privacy on the web.
  Considered related as I think the design proposed here fit well (
  especially High-Level Threats, since these threats no more
  apply when parties can't access user data)
• W3C TAG Ethical Web Principles
• Trusted Execution Environments: conceptually, offline-only storage is a kind of trusted execution environment, but without hardware required. The goal is to allow web apps that want to to operate inside this kind of environment, and to "reward" them for doing so.
• Chrome Privacy Sandbox: I guess could be a good starting point for testing the viability of the feature described here
• discourse.wicg.io topic

EDIT 2021/05/27: realized it's a form of E2E encryption (simpler to describe)
EDIT 2021/05/29: added the Storage Access API as a good candidate for implementing this API on
EDIT 2021/05/30: added links with Fenced Frames read-only mode

[ajpauwels]

Hello all, really enjoy this post. The web has a privacy and data problem, and it stems from its basic storage model as is highlighted in this post.

Redact is an open-source implementation of exactly a protocol like the one described here, with some modifications. For one, there is no deep integration with browser code, the frame implementation is provided via a server that runs locally next to the browser.

Although it is not feature complete and alpha at best, there is a functional "redacted" website which can be accessed and browsed via a regular web browser securely after the basic software is installed locally. It includes:

• Full functional encryption of user data
• A secure frame implementation for standard website hosts to interact with "redacted" user data
• Fully functional federated storage system
• Crypto abstractions for fetching and decrypting data stored in various locations; all crypto implementations are libsodium
• Written in Rust

You can get started with it here: https://docs.redact.ws/en/latest/

If the privacy community group has any interest in discussing something like this I would love to be a part of that discussion!

I'll also drop a link to a discussion in a rust group about this here.

[ghost]

Hi all! An interesting question is it possible to integrate Solid with this proposal here? @ajpauwels @Minigugus @hober @dmarti @chrisn

1. Context

1.1 What is WebAuthn?

WebAuthn is a browser-based API that allows for web applications to simplify and secure user authentication by using registered devices (phones, laptops, etc) as factors. It uses public key cryptography to protect users from advanced phishing attacks.

1.2 Why use WebAuthn?

1. WebAuthn is part of the FIDO2 framework, which is a set of technologies that enable passwordless authentication between servers, browsers, and authenticators. As of January 2019, WebAuthn is supported on Chrome, Firefox, and Edge, and Safari.
2. WebAuthn is supported by the following web browsers: Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari and the Opera web browser. The desktop version of Google Chrome has supported WebAuthn since version 67.

1.3 What is Solid Project?

Solid is a specification that lets people store their data securely in decentralized data stores called Pods. Pods are like secure personal web servers for your data.

1.4 Why use Solid?

1. Any kind of information can be stored in a Solid Pod.
2. You control access to the data in your Pod. You decide what data to share and with whom (be it individuals, organizations, and/or applications). Furthermore, you can revoke access at any time.
3. To store and access data in your Pod, applications use standard, open, and interoperable data formats and protocols.

2. Possible solutions to general information security problems

1. I believe that these proposals here like WebAuthn, Solid and 'Privacy by design with browser-managed E2E encryption are good for ensuring data privacy and security'.
2. I keep asking and wondering if we couldn't put all these proposals together to create an algorithm that is even stronger and safer than ever. Perhaps it is an initial mistake to imagine that it should be possible to have security so good that it is "impenetrable", "secure", "strongest" ever.
3. I have more doubts than the statements I spoke above, I spoke in a sense of concept and idea in terms of draft proposal.
4. WebAuthn is approved as new web standard for passwordless logins. This will allow users of WebAuthn-compatible browsers such as Chrome, Firefox, Edge or Safari to use this API as a mechanism to access their accounts through mobile devices, USB security keys or biometric systems, replacing the use of passwords and, while strengthening security. This system is more secure than one that offers a weak password, like the one often chosen by users.
5. I believe login without passwords is the "best way" - in most cases users create easy passwords that only a brute force, phishing or social engineering attack "is easy to get access to this data, information". In this sense, I was happy with WebAuthn's proposal - because in my opinion it allows users to have an api to use login without passwords and this, in my opinion, is great progress. I know when it comes to data security and privacy and anonymity - there are always good things and bad things. That's why I think of a good path or direction for all sides.
6. I wish there was a single standard for password management, I believe that for this to be done we must have an incredible proposal for it: WebAuthn, Solid and 'Privacy by design with browser-managed E2E encryption are good for ensuring data privacy and security'.
7. My idea here is a doubt if it would be possible to integrate WebAuthn with this proposal here. So... I believe that the most "smart" browsers should manage passwords for the users. And most browsers do just that.

3. "Universal laws for optimal data security"

1. Importing and exporting browser passwords must have a universal and encrypted password pattern. There is a technical discussion about Mozilla Firefox using the encryption format here: Encryption of passwords imported into a file.
   • The problem with passwords today is that every browser implements the way to import and export passwords.
   • I argue that to have good security/privacy of user data we have to have a universal standard in importing/exporting passwords. As a matter of technological, individual, philosophical and rational freedom
   • I believe that for this to be done, we have to adopt the standard of open solutions with MIT/GPL open licenses, etc.
   • Keepass is an open source solution for managing passwords, it would be nice to have the same file format for all web browsers. When I refer to a universal standard for importing/exporting passwords, I say that it would be interesting, as I said before, to adopt the keepass open format for this.
   • Keepass has been around for a long time and is a well-established, popular solution known all over the world.
   • Adopting the Keepass format for importing/exporting passwords gives people more freedom. Well, Keepass software is licensed under the GPL - the same license as Linux. Which, in theory, will always be available openly.
   • It's 2022, and the bookmarks format is the same as it was in 1999. So why don't we have the same Keepass format for importing/exporting passwords in all browsers? - reference here Netscape bookmarks
2. "Data is always from users regardless of whether it is government, company" - Only users can decide whether they want to give their data to governments or companies by contract, agreement, duty, law, free will, free initiative, autonomy - note: I don't know anything about justice, I'm not a lawyer, prosecutor or judge. Any of these points I can be wrong, I spoke here in general. If at this point I said something wrong, correct, criticize, present the fault and the solution. In that case, I will make the correction here.
   • When I talk about user data: I am referring only to registration data in logins or data that talk about users: political, health or philosophical data, etc.
   • And companies or governments can take care of user data only if the users allow it, want it, have the vote to do so.
   • Data security and privacy laws is a way or agreement to say and show this idea/concept.
   • We currently have the Solid pattern that addresses this concept, where users can store certain data in their Pods.
3. "Browsers/websites/plataforms/social media know a lot about users, users don't always like or prefer to read security and data privacy policies". In this sense, passwordless login, e2e encryption can work to support users in general. Knowing this, the proposal here I think agrees with this idea that I write: 'Privacy by design with browser-managed E2E encryption are good for ensuring data privacy and security'.
4. Users cannot always create secure passwords, there must be a way to create passwords for users themselves. This can be done with the Web Authn proposal.

4. My concept

1. Import/export passwords in keepass format for all browsers
2. Create a proposal on data security and privacy at the W3C by joining the following proposals: WebAuthn, Solid and 'Privacy by design with browser-managed E2E encryption are good for ensuring data privacy and security'.
3. Browsers must be compatible with WebAuthn, Solid and 'Privacy by design with browser-managed E2E encryption are good for ensuring data privacy and security'.
4. I found this question here: 'A question is it possible to use the FIDO protocol and hardware keys through E2E in browsers?' in [Proposal] Built-in E2E encryption into web browsers and I want built-in E2E encryption into web browsers+FIDO Protocol and Hardware keys

5. FAQ

The security/privacy risk is still present: compromised front-end code can still intercept user data (even with E2E encrypted apps: listening to DOM changes is enough)

• If the browser is integrated with an offline authentication device, would it be possible to solve this security issue?
• In case of logging in without passwords, we can usually authenticate with a usb device.
• If the browser has E2E on an offline device - maybe it increases security?

A new threat model emerge, where web apps may leak data via QR codes, file system access, and so on. These threats
already exists, but they risk to become more intrusive than before. Anyway, web apps already get flagged as
malicious when they try to harm users so mitigation already available.

• Maybe 'E2E encryption into web browsers+FIDO Protocol and Hardware keys' can be an alternative to solve this kind of problem

6. Notes

1. I would like to know if this idea is good or bad
2. My goal is to help this communities: PrivacyCG, Solid, W3C, WIGC, WebAuthn, KeepPass, Browsers(Brave, Vivaldi, Opera, Mozilla Firefox, Libre Wolf, Google Chrome etc)
3. I didn't find any link, resource for this here in PrivacyCG Community
4. I'm not promoting any company, service, product, solution, idea here - just adding the bibliographic reference links
5. If I'm wrong about something, speak up, criticize, correct

7. References

• https://www.okta.com/blog/2019/03/what-is-webauthn/
• https://www.yubico.com/authentication-standards/webauthn/
• https://en.wikipedia.org/wiki/WebAuthn
• https://solidproject.org/
• https://solidproject.org/about
• https://connect.mozilla.org/t5/ideas/firefox-mobile-needs-a-master-password/idi-p/1231
• https://docs.redact.ws/en/latest/
• https://github.com/WICG/turtledove
• Privacy-Safe Storage API #28
• https://w3ctag.github.io/privacy-principles/
• https://www.w3.org/2001/tag/doc/ethical-web-principles-20211215
• https://www.chromium.org/Home/chromium-privacy/privacy-sandbox/
• https://en.wikipedia.org/wiki/Trusted_execution_environment
• https://discourse.wicg.io/t/building-websites-that-cannot-read-exfiltrate-or-store-the-data-they-operate-on/5729
• https://webauthn.guide/
• https://en.wikipedia.org/wiki/SQRL#Benefits
• https://en.wikipedia.org/wiki/SQRL#Example_use_case
• https://en.wikipedia.org/wiki/SQRL#SQRL_implementations
• https://en.wikipedia.org/wiki/SQRL#Legal_aspects
• https://en.wikipedia.org/wiki/Mozilla_Persona
• https://en.wikipedia.org/wiki/OAuth
• https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)
• https://en.wikipedia.org/wiki/Single_sign-on
• https://en.wikipedia.org/wiki/Password_manager
• https://en.wikipedia.org/wiki/Usability_of_web_authentication_systems
• https://en.wikipedia.org/wiki/Account_pre-hijacking
• https://en.wikipedia.org/wiki/Proof_by_exhaustion
• https://en.wikipedia.org/wiki/Brute-force_attack
• https://en.wikipedia.org/wiki/Brute-force_search
• https://en.wikipedia.org/wiki/FIDO_Alliance
• https://en.wikipedia.org/wiki/Central_Authentication_Service
• https://en.wikipedia.org/wiki/Light-weight_Identity
• https://keepass.info/
• https://dl.acm.org/doi/abs/10.1145/2628071.2628118
• https://www.os3.nl/_media/2013-2014/courses/rp1/p07_report.pdf
• https://ulir.ul.ie/bitstream/handle/10344/116/09sqrl1000.pdf?sequence=2
• https://ieeexplore.ieee.org/abstract/document/8440957
• https://www.veracode.com/security/owasp-top-10
• https://owasp.org/www-project-top-ten/
• https://owasp.org/www-community/vulnerabilities/
• https://ieeexplore.ieee.org/abstract/document/7873914
• https://link.springer.com/chapter/10.1007/978-3-662-60911-8_13
• https://owasp.org/www-community/attacks/
• https://owasp.org/www-project-top-ten/
• https://keepass.info/help/base/firststeps.html
• https://keepass.info/help/base/faq_tech.html
• https://en.wikipedia.org/wiki/SQRL
• https://doubleoctopus.com/security-wiki/protocol/secure-quick-reliable-login/
• http://fileformats.archiveteam.org/wiki/Chrome_bookmarks
• https://wiki.mozilla.org/Bookmarks_Use_Cases
• https://www.w3.org/wiki/Privacy/TPWG/Proposals_on_the_definition_of_context#Abandoned_Proposals
• https://www.w3.org/wiki/Privacy/TPWG/Change_Proposals_on_data_minimization
• https://www.cpomagazine.com/data-privacy/google-blocking-web-privacy-proposals-at-w3c/
• https://www.w3.org/Privacy/IG/
• https://www.protocol.com/policy/w3c-privacy-war
• https://triplelift.com/privacy-hub/w3c-proposals-explained-privacy-with-a-side-of-chips/
• https://www.wikidata.org/wiki/Q28786544
• https://support.mozilla.org/en-US/questions/1319392
• https://community.bitwarden.com/t/sign-in-using-qr-code-without-master-password/15727/45

[Minigugus]

there is no deep integration with browser code, the frame implementation is provided via a server that runs locally next to the browser.

@ajpauwels I think you've understood the main point of this proposal 👍 Yet, running a local server, plus using a lot of iframes risk to slow down adoption of this proposal. Moreover, security measures are best implemented at browser level (for instance with Redact, it's not possible to protect against malicious web extensions).

If possible, like you, I would like to discuss this proposal further with those interested 🙂

2. You control access to the data in your Pod. You decide what data to share and with whom (be it individuals, organizations, and/or applications). Furthermore, you can revoke access at any time.

The goal of this proposal is especially to avoid privacy issues by never sharing user data with third-parties, so I don't think Solid is compatible and comparable with this project. Also, letting users choose what they want to share would require a common data format for data storage, which is really constraining both for website developers and browsers developers.

However, this proposal encourage WebAuthn for authentication with the storage provider.