Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

DP: fix Laplace calibration (F4) and label post-training mechanisms experimental (F5)

Abierto
  • ¿Algo no está bien?
#279 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@Abidoyesimze ya está trabajando en esto.

Desde el 27/10/2026.

  • #288 de @Abidoyesimze — abierto
  • #292 de @Abidoyesimze — abierto
  • #293 de @Abidoyesimze — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
64/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
machine-learning, security

Línea de trabajo

For Track A, read cache_model_0/services/client.py, Documentation/technical/services/clients.md, and tests/test_cache_client_dp.py. Add a warning when either post-training mechanism is selected and cover it with a test; done means the warning identifies the mechanisms as experimental with no formal privacy guarantee and the docs match. Track B needs differential privacy expertise, while Track C requires real trained weights and accuracy evaluation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

good first issue help wanted

Summary

Three open items remain from our DP mechanism review (PR #89) and its follow-up fixes (#90, #109, #119). None of them has a GitHub issue yet; two are tracked only in Developer/BACK_LOG.md (BL-23, BL-24).

DP is off by default on DevNet, and our public docs avoid claiming formal differential privacy. The goal here is that, when a model owner turns DP on, every mechanism we offer either carries an honest guarantee or is clearly labelled as not having one.

The three items

F4 / BL-24: Laplace noise is sized against an L2 clip.
post_training_laplace multiplies laplace_scale by the L2 clipping_norm (cache_model_0/services/client.py, require_laplace_scale(params) * clipping_norm), but the Laplace mechanism is calibrated against L1 sensitivity. For model weights, the gap can be up to √d (d = number of parameters), so this mechanism cannot carry any ε today. The docs already note it as an open question (Documentation/technical/services/clients.md).

F5: the post-training mechanisms bound no sensitivity at all.
Both post_training_gaussian and post_training_laplace clip absolute trained weights rather than per-client updates, so they bound nothing an attacker cares about. The review recommends labelling both as experimental baselines with no formal guarantee, and treating update_gaussian as the path forward. Today only the per_layer clip scope is labelled experimental in the docs.

BL-23: the default clip may be destructive on real models.
Since #109, clip_scope: global bounds the whole model's combined L2 norm, but cache_model_0/manifest.json still uses clipping_norm: 1.0, chosen under the old per-layer scope. Tests use synthetic tensors only, so nobody has checked whether this default badly degrades the reference model's real trained weights.

Ways to help

Track A: honest labelling (newcomer-friendly, no DP expertise needed)
  • Emit a clear warning when post_training_gaussian or post_training_laplace is selected (log message or manifest-validation warning): experimental, no formal privacy guarantee.
  • Update Documentation/technical/services/clients.md to match.
  • Add a test in tests/test_cache_client_dp.py covering the warning.
Track B: specialist recommendation for F4 (DP expertise wanted)
  1. Is the mismatch as described, and how large is it in practice for typical model sizes?
  2. Which resolution would you recommend?
    • an update_laplace mechanism: L1-clip the per-client update and add calibrated Laplace noise, mirroring update_gaussian;
    • keep post_training_laplace only as a labelled experimental baseline (Track A);
    • remove the Laplace option entirely.
  3. Given F5, is there any reason to keep weight-level mechanisms at all?

A written recommendation in a comment is a valuable contribution on its own; a PR is even better.

Track C: verify the default clip (ML / Python, moderate)

Run apply_dp_mechanism / clip_state_dict against cache_model_0's actual trained weights under the current default. Report how much the clip changes them and the effect on accuracy, then propose a better clipping_norm if 1.0 is destructive. Ideally add a test using real weights.

Longer-term context

Privacy accounting and DP-SGD (review finding F6) are the bigger roadmap items, described in Developer/issues/DifferentialPrivacy.md. They're out of scope here, but proposals are welcome as separate issues.

cc @tudorcebere : we'd especially value your view on Track B, given your background in privacy-preserving ML. No obligation, of course.

Lenguaje dominante
Python
Estrellas
4
Forks
7
Merge medio
3 d 58 min
PR fusionados (30 d)
39

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de InfiniteZeroFoundation/DevNet

Todos los issues de InfiniteZeroFoundation/DevNet

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.