> "We want social media companies to confirm they will not implement end-to-end encryption until they have the technology in place to ensure children will not be put at greater risk as a result."
Most of these companies already know the users birthday, if this is only about child abuse then instead of adding backdoors for everyone, why not just disable end to end encryption conversations for users under 16?
Doesn't that open up a whole new can of worms, though, because it would require the operator of every service to check the age (and by extension, identity) of every user of their service, so as not to inadvertently E2EE the communications of a child? Passing off this verification to a Trusted Third Party (wink wink) is just as bad (probably worse), because you would be make it even easier for the government to tie it into a̶ ̶s̶o̶c̶i̶a̶l̶ ̶c̶r̶e̶d̶i̶t̶ ̶s̶y̶s̶t̶e̶m̶
whatever they have planned for the next stage.
If a child wants to be "protected" online then it would be up to them to enter their actual age. But you are right, the government will take any excuse to get users verifying their age.
This is a valid concern with using any third party mail provider. Even if you own the domain though, you probably use a domain provider, for which it would be un-wise to use your own domain as the login email. Do you really have full ownership of any email address?
I Initially thought Gatsby was great. As someone who enjoys using React, being able to use it for web sites in a way that’s well optimized and SEO friendly was appealing.
However… after using Gatsby for a fairly simple site it didn’t take me long to realise that this approach add’s a fair bit of complexity and limitations. Prepare for long build times for simple changes, which becomes a bit silly once you hook up a CMS that triggers builds for each change. As a content editor having to wait 5 minutes for your change to be deployed kinda sucks. GraphQL for loading data often felt overkill and a lot of hassle. If you want to add something like a simple contact form you are encouraged to use external services which just get’s out of hand for what I want to be a simple self-contained site. The end result doesn't even feel that fast due to the React re-hydration that takes place.
I ended up switching back to a traditional server-side solution which provided a much faster experience (in both tests and perceived speed) and more flexibility. It turn’s out the browser is pretty good at caching static assets and you can achieve the same SSG benefits with Caching and a CDN without the restrictions.
I’m sure there are cases where Gatsby performs well, and it’s the best tool I’m aware of for bundling React pages in an SEO friendly, optimised way. But I think for the kind of project’s it’s useful for, something like Jekyll or Hugo may be more suitable. For more complex site’s that would actually benefit from React, it seems like the SSR alternative (Next) would be easier to scale.
