Open Minigugus opened 2 years ago
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:
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.
Hi all! An interesting question is it possible to integrate Solid with this proposal here? @ajpauwels @Minigugus @hober @dmarti @chrisn
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.
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.
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
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 :+1: 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 :slightly_smiling_face:
- 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.
Offline-only storage
Here is a summarized description of traditional architecture for web apps:
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:
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):
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):
As shown above, the proposed solution consist of 2 parts:
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
Cons
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 whichfetch('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. viapostMessage
(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:
navigator.offlineStorage.enable()
):enable()
)location.reload()
to leave the trusted context without leakpostMessage()
)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:
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
28: original idea, but not attractive enough (was too restrictive on implementation details and did not solve the
data mobility issue)
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