kevinmcareavey
commented
2 years ago A1 – poison input is treated as standard input These inputs are injected using standard API requests and the system behaves as it would for any standard input, e.g.:
curl --request PUT 'https://api.project-chai.org/heating/mode/?label=test_home_kevin' --header 'Authorization: Bearer 8dbb9774-970c-4f9d-8992-65f88e501d0e,b7b100ed0a9e8e54af91ece8' --header 'Content-Type: application/json' --data-raw '{"mode": "auto", "target": 30}'
curl --request PUT 'https://api.project-chai.org/heating/mode/?label=test_home_kevin' --header 'Authorization: Bearer 8dbb9774-970c-4f9d-8992-65f88e501d0e,b7b100ed0a9e8e54af91ece8' --header 'Content-Type: application/json' --data-raw '{"mode": "auto", "target": 30}'
curl --request PUT 'https://api.project-chai.org/heating/mode/?label=test_home_kevin' --header 'Authorization: Bearer 8dbb9774-970c-4f9d-8992-65f88e501d0e,b7b100ed0a9e8e54af91ece8' --header 'Content-Type: application/json' --data-raw '{"mode": "auto", "target": 30}'Nothing more is required from the API or backend.
The attack(s) will be orchestrated and triggered by a script written by Greenwich, to be reviewed by Bristol.
A3 – poison inputs are hidden from the user
One option is that inputs are injected in the same way as A1 except for the addition of an optional Boolean field hidden (default hidden=false) in the body of the PUT /heating/mode/ request, e.g.:
curl --request PUT 'https://api.project-chai.org/heating/mode/?label=test_home_kevin' --header 'Authorization: Bearer 8dbb9774-970c-4f9d-8992-65f88e501d0e,b7b100ed0a9e8e54af91ece8' --header 'Content-Type: application/json' --data-raw '{"mode": "auto", "target": 30, "hidden": true}'A corresponding hidden column would be required in the DB with any relevant API GET requests omitting entries with hidden=true.
The tricker part is that the system should not enter override mode if the triggering input includes hidden=true. Aside from this the system should otherwise behave as usual, e.g. the ML model should still be updated and, if the system was in auto mode at the time of the attack, the new prediction (from the updated ML model) should be adopted as the new setpoint.
The attack(s) will be orchestrated and triggered by a script written by Greenwich, to be reviewed by Bristol.
A2 – prices are manipulated
Manipulated prices x' will be derived from a constant multiplier m applied to real prices x, i.e. x' = x * m. The multiplier m is to be decided by Greenwich.
Attacks will be triggered manually somehow, but may be terminated manually or in an automated way (e.g. after k timesteps, or at a given datetime), whatever is technically easier.
Manipulated prices should permanently override the real prices for the attack period, so users will henceforth only see the manipulated prices during that period.
One option is to include a new API endpoint that accepts the multiplier and a terminating condition, but it is unclear how best to handle the actual overriding of prices.
kimbauters
georgeloukas
eddy211821
The API needs to be able to simulate attacks. Three types of attacks are considered:
A1 – poison input is treated as standard input A2 – prices are manipulated A3 – poison inputs are hidden from the user
Further input and discussion is needed to determine how each attack is logged, manifests itself, and how it is triggered.