For some reason that article doesn't link to it, but it is a real tweet he made in February (and didn't even delete after being called out for the highlighted search terms in his screenshot).
Regarding your browser-based thing: what are the specific capabilities of the "threat agents" (in your threat model's terminology) which your e2ee is intended to protect against?
It seems like the e2ee is not needed against an attacker who (a) cannot circumvent HTTPS and (b) cannot compromise the server; HTTPS and an honest server will prevent them from seeing plaintext. But, if an attacker can do one of those things, does your e2ee actually stop them?
The purpose of e2ee is to protect against a malicious server, but, re-fetching JavaScript from the server each time they use the thing means that users must actually rely on the server's honesty (and HTTPS) completely. There is no way (in a normal web browser) for users to verify that the JavaScript they're executing is the correct JavaScript.
If you run a browser-based e2ee service like this and it becomes popular, you should be prepared that somebody might eventually try to compel you to serve malicious JavaScript to specific users. Search "lavabit" or "hushmail" for some well-documented cases where this has happened.
TiVo complied with the GPLv2 and distributed source code for their modifications to Linux. What they did not do was distribute the cryptographic keys which would allow TiVo customers to run modified versions it on their TiVo devices. This is what motivated the so-called anti-tivoization clause in GPLv3 (the "Installation Information" part of Section 6. Conveying Non-Source Forms.).
Linux remains GPLv2, so, everyone today still has the right to do the same thing TiVo did (shipping it in a product with a locked bootloader).
Distributing Linux (or any GPLv2 software) with a threat of violence against recipients who exercise some of the rights granted by the license, as is depicted in this post, would be a violation section 6 of GPLv2 ("You may not impose any further restrictions on the recipients' exercise of the rights granted herein.").
Lmao. Even CBP does not claim that. On the contrary, they say (and courts have so far agreed) that they can perform these types of border searches without any probable cause, and even without reasonable suspicion (a weaker legal standard than probable cause).
In practice they routinely do it to people who are friends with someone (or recently interacted with someone on social media) who they think could be a threat, as well as to people who have a name similar to someone else they're interested in for whatever reason, or if the CBP officer just feels like it - often because of what the person looks like.
It's nice for you that you feel confident that you won't be subjected to this kind of thing, but you shouldn't assume OP and other people don't need to be prepared for it.
Ultimately you shouldn't cross the US border carrying devices or encrypted data which you aren't prepared to unlock for DHS/CBP, unless you're willing to lose the hardware and/or be denied entry if/when you refuse to comply.
Device searches were happening a few hundred times each month circa 2009 (the most recent data i could find in a quick search) but, given other CBP trends, presumably they've become more frequent since then.
In 2016 they began asking some visa applicants for social media usernames, and then expanded it to most applicants in 2019, and the new administration has continued that policy. I haven't found any numbers about how often they actually deny people entry for failing to disclose a social media account.
They had to make it the default though. That was unavoidable.
For it to be useful at scale, sure, but reading this it sounds like Chrome's version of it is still "experimental" and opt-in. Hopefully the backlash prevents it from being developed further.
It has come to my attention that many of the people complaining about #Firefox's #PPA experiment don't actually understand what PPA is, what it does, and what Firefox is trying to accomplish with it
The documentation under the "Learn more" link next to the "Allow websites to perform privacy-preserving ad measurement" checkbox in Firefox preferences explains very clearly what it is and how it works. Asserting that people who read that and are indignant about it being enabled by default just... "don't actually understand" it is absurdly insulting and basically gaslighting.
It seems to me that switching SIMs provides little privacy benefit, because carriers, data brokers, and the adversaries of privacy-desiring people whom they share data with are obviously able to correlate IMEIs (phones) with IMSIs (SIMs).
What kind of specific privacy threats do you think are mitigated by using different SIMs in the same phone (especially the common practice of using an "anonymous" SIM in a phone where you've previously used a SIM linked to your name)?
At my workplace, we use the string @nocommit to designate code that shouldn’t be checked in
That approach seems useful but it wouldn't have prevented the PyPI incident OP links to: the access token was temporarily entered in a .py python source file, but it was not committed to git. The leak was via .pyc compiled python files which made it into a published docker build.
democracy dies in dark mode