{"version":"2.1.299","anchor":"remote-io-ccrclient-reads-own-client-events-and-holds-idle-l","canonical_anchor":"remote-io-ccrclient-reads-own-client-events-and-holds-idle-l","heading":"Cloud sessions now check device attestation on their own stored events","tier":"internal","area":"Cloud Sessions","scope":"org","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299\/e\/remote-io-ccrclient-reads-own-client-events-and-holds-idle-l","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.299","markdown":"### Cloud sessions now check device attestation on their own stored events\n\nCloud sessions reading back their own stored events now check device attestation against policy and treat failing events as unavailable\n\n**Unclear.** What, if anything, this changes in what a person using a cloud session sees is not known.\n\n**What**\n\nDevice attestation is a statement from a device vouching for its own state. When a cloud session reads back an event it stored earlier, it now checks that event's attestation against the session's policy. If the policy is unknown or the event does not state its attestation, the event is reported as unavailable. If the policy is enforced and not met, the event is treated as missing.\n\nCloud sessions also gained a way to keep an idle connection open, and renewal of the session's statement now goes through the session's connection to the server.\n\n**Why**\n\nThis tightens which stored events a cloud session will trust.\n\n- Area: Cloud Sessions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 4\/5\n- Scope: org\n- Heads-up: no"}