Starlink requires hardware on the ground that cannot easily be hidden, which enables corrupt governments to tear that hardware down or put pressure on the maintainers of that hardware in other ways.
> Then TikTok came along and it's kind of disproven that? ... none of the algorithmically generated content is as polarizing as what I would find on the other apps.
I don't think this is fully accurate. The big differentiator for Tik Tok's algorithmic feed from FB's or Youtube's (in my mind) is not its accuracy or lack of polarization, it's actually that it draws much firmer and harder to cross lines between the parts of its userbase with an (IMO intentionally) nerfed search capability, so it's very difficult to break out of the demographic/interest bubble it decides you are in for feed purposes. So you, personally, probably receive literally no polarizing, political, etc content that you aren't happy to see. But that doesn't mean it's not there!
Here's an example: a researcher set up a new account, interacted with transphobic content, and was very quickly (in a few hours of viewing) seeing far-right conspiracy theory, antisemitic, white supremacy (and so on) content, some of which was endorsing violence. https://twitter.com/abbieasr/status/1445888305997000705
ByteDance (字节跳动) the parent company that owns TikTok and mainland china Douyin 抖音 have been caught suppressing and hiding videos from disabled or LGBTQ users so that they are not shown to regular users. [0] [1]
One might wonder what other content is suppressed on the platform. [2]
In my personal experience with tiktok it will pigeonhole you rapidly. But overall the platform is heavy on silly and fun content (not sure if it intentionally maintained like that by the owners). So before you know it you are pigeonholed into extremely fun stuff (compared to tediously polarizing content on other big apps).
Now over time it might devolve into bad content if there is no higher level moderation to keep it on lighter side of things. I would personally be okay with not all platforms being totally democratic.
This is additionally confusing because different prominent platforms use different systems - eg, 1500ish is the 50th percentile on lichess (used in the blog post), but chess.com (which many streamers / online commentators use) has more like an 1100 midpoint for its ELO-approximating system, and 1500 is reasonably high there (it also varies with time control I believe). And USCF+FIDE use other systems altogether.
It's basically impossible to discuss chess ratings or changes in them without "type" information :)
I believe Megacrit, which built Slay the Spire, is two people, Casey Yano and Anthony Giovannetti. But to the broader point I knew the name of the studio off the top of my head while I needed to look up the names of the individuals.
However, in practice, using "Sign in with Google" by default dramatically increases resilience to most failure modes for almost everyone without a sophisticated threat model.
> To save what? An additional password?
The average person does not manage their passwords in a sophisticated way; if someone is signing up for many different services, they are probably using the same password everywhere, or some simple enumeration scheme. Then, when some random forum or web service gets compromised (as they inevitably are), their password to everything is compromised - including Google! On the opposite end of the spectrum, if Google is the only service with a password, and everything else is driven by Google-owned SSO, that person is essentially immune to compromise; whatever I think about the company, I do believe in Google's security team to keep passwords safe and block dictionary attacks more than any other service on the internet.
And while we can evangelize setting up password managers and using strong random passwords everywhere, the truth of the matter is that many people simply cannot accomplish this. "Sign in with {Google, Facebook, Microsoft}" gets them 95% of the benefit at much higher reliability.
> if someone is signing up for many different services, they are probably using the same password everywhere, or ...
This is completely the case, and at least from my experience the reality is worse than what is often believed: people don’t have distinctions between websites.
i.e. if a layman registers john@cool-website.invalid:correctStaple, and then they open another-sitename.invalid the other day, and presented with login screen, his intuition will be “john@.:correctStaple has to work”, because that’s what he “entered” yesterday.
Federated sign-in solves this by allowing users to use coherent id:password string for any login page without having to have distinctions between domains.
Strongly agree! And if Google closing your account is a big part of your threat model, that's something to hedge against.
But I suspect that for the average consumer - people using their gmail to send and receive emails, and doing stuff like watching Youtube and installing Android apps - the odds of that are quite small, especially if they don't have a business or developer context associated with their personal gmail. Account loss/takeover due to password re-use is a much bigger threat for the average person.
The end of the post is extremely specifically and carefully not describing a framework for rolling out files to exploit these vulnerabilities; those files as described do nothing, and serve only aesthetic purposes. While it's easy to read that as a wink that they are exploiting the vulnerabilities they found while maintaining plausible deniability that they aren't, it's equally possible it's the other way around: they aren't rolling out exploits but want people reading the blog post to believe that they are. Or that they want to lay out the framework so that others can do so, but aren't actually going to follow through themselves. As written it's essentially unverifiable, obviously on purpose.
The optimal thing for them to do would be to build the framework and ship partially corrupted JPEGs that don't actually do anything nasty to Cellebrite. Cellebrite can verify that the machinery is there (not a totally idle threat) but no one can prove that Signal has actually done anything illegal. Cellebrite then wastes a bunch of times gathering and analyzing the files without actually learning anything from it. They also get more incentive to start finding and fixing their software's vulnerabilities, which throws off work schedules.
And Signal can develop a few land mines to deploy at any time, and just... hold on to them for a rainy day.
Even if Signal put the files out there and explicitly owned up to it, I struggle to see how it could be even remotely illegal. It's not their fault some other company's faulty product falls apart when it hits bad data in their app.
Agreed. Obviously, I'm not a lawyer so who knows. But it seems ridiculous that you could break into someone else's device and run all of their files and then come after them legally because a file you effectively stole didn't run properly on your computer.
At some point if someone breaks through multiple levels of advanced security to, say, steal your gun and then shoot themselves in the face with it, whose fault is that really...
I dislike finding myself defending Apple, but these complaints are essentially unfounded.
The butterfly keyboard issue is so noteworthy because it is a dramatic departure from the normal quality levels of Apple products. The only other major (modern) hardware quality issue in an Apple product I can think of is the iPhone 4 antenna thing from 2010; I would be hard-pressed to find another hardware company that's shipped as few problematic products on that time frame, and for many companies a butterfly keyboard style quality issue would be unremarkable! Can you name a company that does consistently better than Apple on hardware quality?
The Apple root password bypass was not good (four years ago), but the set of people with a threat model such that this really mattered is not large (I think it was only ever proven to work with physical access to the device, for example). The "goto fail" bug[1] was also quite bad, in fairness. But on the same time frame neither of those really registers as a vulnerability on the same level of impact as Heartbleed[2], Cloudbleed[3], Spectre[4] and related issues, or even the more recent Solarwinds[5] or Exchange[6] hacks. Every software company has security incidents; Apple is absolutely not an outlier or unusually insecure.
Dropbox does not have client-side encryption; its servers have full access to the content of synced files. You can verify this yourself by uploading a common image filetype like jpeg and seeing that the website shows you compressed file thumbnails.
(I'm a former Dropbox employee who worked on related things, though not specifically the linked paper)
Yep, that makes sense. IIRC, they also have some sort of global deduplication system, don't they? That also implies they have access to your unencrypted files.
Edit: That's what I get for commenting before reading the paper. They literally mention deduplication in there.
Not necessarily. You could use homomorphic encryption and, for example, encode the file with a hash of the file as the key material for encryption. All such files will encode identically for each user, but it will be opaque to the server what the contents are unless the server already has the plain-text of the original file. This was used by other cloud storage companies (that are now defunct).
> Not necessarily. You could use homomorphic encryption
I think that's still far from being possible in practice. IIRC, the best homomorphic encryption can do now is to run simple queries on very small datasets, on a supercomputer, with performance of a 386?
Mega does client side e2e encryption (or at least they claim to), yet their web interface still shows thumbnails...
I'd guess they implement it by having the client upload an encrypted version of both the original image and a thumbnail, and then decrypting the thumbnails on the client at display time. Javascript has reasonably performant crypto primitives now, so it's very doable to download data from a server, decrypt it with a client side key, and display it.
If mega can do this, it's a shame other services don't.
It's not a misconception. As an example, here's a video of riot-gear-clad police marching on a crowd that is peacefully listening to a violin vigil for a man murdered by that same police department: https://twitter.com/jessiedesigngal/status/12771260192462602...
The parent claimed that it was a misconception that police were "quelling" peaceful protest and I shared a video of police disrupting a very obviously peaceful protest - feels relatively straightforward?
Watching the original video, do you legitimately believe that any of the police officers are in danger? Do you believe that a single (unsubstantiated claim, without any evidence of a) thrown object justifies pepper spraying reporters and attacking bystanders with batons?
I originally shared the video claiming that police were interfering with a peaceful protest. You disputed that the police were interfering, saying they were marching past. When I shared further evidence that the police were in fact disrupting the protest and hurting people who were participating, you found reason to instead believe that the protest was not peaceful. Consider your biases.
Here [0] [1] [2] [3] are more examples of and news articles discussing police attacking peaceful protesters.
