The goal of this page is to high-light the lack of coverage AWS provides for its services across different security factors. These limitations are not well-understood by many. Further, the “Y” fields are meant to indicate that this service has any capability for the relevant factor. In many cases, this is not full coverage for the service, or there are exceptions or special cases.
Is modeling my relational database in a single DynamoDB table really a good idea? About a year ago, I wrote a fairly popular article called “Why DynamoDB isn’t for everyone”. Many of the technical criticisms of DynamoDB I put forth at that time (lack of operational controls such as backup/restore; a persistent problem with hot keys) have since been partially or fully resolved due to a truly awe-inspiring run of feature releases from the DynamoDB team. However, the central argument of that article remains valid: DynamoDB is a powerful tool when used properly, but if you don’t know what you’re doing it’s a deceptively user-friendly guide into madness. And the further you stray into esoteric applications like relational modeling, the more sure you’d better be that you know what you’re getting into. Especially with SQL-friendly “serverless” databases like Amazon Aurora hitting their stride, you have a lot of fully-managed options with a smaller learning curve.
Now that GCHQ have asked for this, I suspect plenty of other government bodies around the world will be looking for similar.
They’re talking about adding a “feature” that would require the user’s device to selectively lie about whether it’s even employing end-to-end encryption, or whether it’s leaking the conversation content to a third (secret) party. Is the security code displayed by your device a mathematical representation of the two keys involved, or is it a straight-up lie? Furthermore, what’s to guarantee that the method used by governments to insert the “ghost” key into a conversation without alerting the users won’t be exploited by bad actors? Despite the GCHQ authors’ claim, the ghost will require vendors to disable the very features that give our communications systems their security guarantees in a way that fundamentally changes the trust relationship between a service provider and its users. Software and hardware companies will never be able to convincingly claim that they are being honest about what their applications and tools are doing, and users will have no good reason to believe them if they try. And, as we’ve seen already seen, GCHQ will not be the only agency in the world demanding such extraordinary access to billions of users’ software. Australia was quick to follow the UK’s lead, and we can expect to see similar demands, from Brazil and the European Union to Russia and China. (Note that this proposal would be unconstitutional were it proposed in the United States, which has strong protections against governments forcing actors to speak or lie on its behalf.) We must reject GCHQ’s newest “ghost” proposal for what it is: a mandated encryption backdoor that weakens the security properties of encrypted messaging systems and fundamentally compromises user trust.
OK-ish way to add dependencies to your Lambda containers:
Decent new Dublin food blog — reviews and news. Like a Harbo-free version of Lovin’ Dublin