From b679ca5cc211d8318a448931707a74833218ae2b Mon Sep 17 00:00:00 2001 From: peterc-s Date: Fri, 1 May 2026 16:08:54 +0100 Subject: [PATCH] Remove design MDs --- design/.gitignore | 1 - design/PHILOSOPHY.md | 49 -------------------------------------------- design/STRUCTURE.md | 12 ----------- 3 files changed, 62 deletions(-) delete mode 100644 design/.gitignore delete mode 100644 design/PHILOSOPHY.md delete mode 100644 design/STRUCTURE.md diff --git a/design/.gitignore b/design/.gitignore deleted file mode 100644 index bc177d7..0000000 --- a/design/.gitignore +++ /dev/null @@ -1 +0,0 @@ -ideation/ diff --git a/design/PHILOSOPHY.md b/design/PHILOSOPHY.md deleted file mode 100644 index 034c1d8..0000000 --- a/design/PHILOSOPHY.md +++ /dev/null @@ -1,49 +0,0 @@ -# What is Chaff? -Chaff is a framework for developing and using Website Fingerprinting (WF) defences. - -## Key Aims -- Improve developer experience over prior works, such as Maybenot[^1] and WFDefProxy[^2]. -- Allow defence developers to create defences that are: - - Auditable - - Portable - - Expressive -- Integrate security estimation techniques so defence developers can test their defences for - robustness. -- FFI for languages such as Python and C in the hopes that: - - It makes training ML-based defences easier through the vast number of ML libraries Python has - to offer. - - Integration into existing Privacy Enhancing Technologies (PETs) such as Tor becomes easy. - -# Design -## Motivation -- Some existing frameworks such as Maybenot and the Tor circuit padding framework[^3] limit - developers in what they may implement by representing defences as state machines. While this makes - machines easily auditable and, in the case of the Tor circuit padding framewor, genetically - trainable[^4], it makes certain classes of defences impossible to implement faithfully (as seen in - the Maybenot paper). -- Other frameworks are now outdated and [include known unsafe libraries](https://github.com/websitefingerprinting/wfdef/blob/3fee6d65d049488584a73db0bb80f071af19d259/common/ntor/ntor.go#L207). -- Developing a tool that allows WF researchers to both implement defences and test them, producing - sound analytics, may accelerate WF defence research. - -## Design Philosophy -- Auditability: - - The core of Chaff should not rely on countless large libraries with many dependencies of their - own. Library usage must be thoughtful and easily auditable. -- Portability/Deployability: - - Chaff defences should be easily transferable between machines. This means that, for example, - deploying a Chaff defence as a Tor Pluggable Transport (PT) must be easy to do. -- Expressiveness: - - Ideally, Chaff should allow the defence developer to create whatever they can imagine as an - effective defence without friction. -- Modularity: - - Chaff should be extensible via modules or plugins with the aim of keeping up with advances in - WF defences. -- Quality: - - Code should be of high quality and easily readable (therefore auditable). - - Chaff should undergo intensive testing and fuzzing. - - Written in a memory safe language with any FFI tested properly and documented thoroughly. - -[^1]: https://github.com/maybenot-io/maybenot -[^2]: https://github.com/websitefingerprinting/wfdef -[^3]: https://gitlab.torproject.org/tpo/core/tor/-/blob/main/doc/HACKING/CircuitPaddingDevelopment.md -[^4]: https://github.com/pylls/padding-machines-for-tor/tree/master/machines/phase2 diff --git a/design/STRUCTURE.md b/design/STRUCTURE.md deleted file mode 100644 index 39cd533..0000000 --- a/design/STRUCTURE.md +++ /dev/null @@ -1,12 +0,0 @@ -# Structure -The project is structured as follows: -- The root `flake.nix` contains the CI/CD build and testing, it also provides a dev shell that - provides the same toolchain as the CI/CD. CI/CD pipelines are specified in `.github/workflows`. -- Crates for the different parts of Chaff reside in `crates/` -- The workspace `Cargo.toml` contains project-wide settings and the crates in the `crates/` - directory must use workspace settings unless explicitly reasoned otherwise. - -## Crates -- `chaff` - the main library for Chaff. Contains all the key functionality. -- `chaff-cli` - the CLI which wraps the `chaff` library. -- (not yet implemented) `chaff-numpy` - I think it might be best to separate out Numpy ndarray compatability into its own crate so no extra dependencies. May even be good to separate out the `capture.rs` module?