> On 9 Nov 2019, at 11:40, Gregory Casamento <greg.casame...@gmail.com> wrote: > > Does anyone have any clue how we are going to tackle NSSecureCoding? I don't really understand it. The basic principle of it is simple: make hacking of archives by an attacker harder by preventing the attacker from substituting different classes into the archive. This uses a new -decodeObjectOfClass:forKey: method to decode objects of a specific class (easy to implement), plus a trivial method/property -supportsSecureCoding to say whether a class does secure coding or not. So the alterations are simple, but extensive and time consuming to implement (we'd need to retrofit/add this to decoding of most classes). My problem with it is that it's hard to see how it can work when it comes to collections ... yet the Apple documentation says that (for instance) NSSet supports secure coding. That should mean that an NSSet decodes its contents with -decodeObjectOfClass:forKey: specifying the class of each object the set holds. However, a set holds arbitrary values (any class), so presumably it would have to decode its contents using NSObject as the class, effectively that's the same as using -decodeObjectForKey: and allows unconstrained alteration of the set contents by an attacker, defeating the whole point of secure coding. It suggests to me that having arbitrary collection classes claim to implement NSSecureCoding would be misleading/wrong. So presumably I'm missing/misunderstanding something about this.