I went to look for the video and somehow was worse than I had imagined.

Yes, an exploitative thing that mostly consists of free labour for big orgs.

Our starting point for design is longevity, which means making our devices more repairable, a very different approach to the electronics industry standard. To support maximum longevity and because of the IP rating, Fairphone 4 does not feature a headphone jack. In the end, it comes down to how we make a product that lasts for at least five years. We needed to eliminate as many vulnerabilities as possible, and the headphone jack is subject to dust and water ingress over time.

Again, you might disagree, you might know better, I don’t know. But this is their motivation when it comes to longevity and hence sustainability. To me, it seems a reasonable idea: if the jack helps reducing the consumption of batteries in headphones but decreases the lifespan of the phones, it seems a bad tradeoff.

They have literally an explanation for this on their website. You might disagree, but saying “it makes no sense”…makes no sense.

Also, they discontinued the earbuds and still no jack on FP5, so the idea that “they wanted to sell their own buds” doesn’t seem to be likely.

Of course, but I assume elderly people getting familiar with a completely new technology need anyway some kind of personal support and introduction from someone close. I don’t think anybody would plan to throw a Mac at some elderly person and say “if any issue call Apple support”, right?

I get your point though, and I am just saying that there are situations where Linux might work totally fine.

Also, the used market for apple product is not that big where I lived. Nobody in the family had a Mac also, which means she wouldn’t have had anybody to ask for support at all. It’s a specific situation, but my point is that having an official support is not going to help that much in some cases.

I find Mac to be extremely unintuitive in how things are organized tbh, but that’s just me.

Anyway, you are right, but she wanted to spend just 3-400 euros for a laptop, which is incompatible with Apple prices. Obviously this means being there to support if something goes wrong, but with a minimal install and Linux being stable, it doesn’t happen often (I also have my mom’s laptop running mint). I do have a reverse tunnel script configured that allows me to SSH in their machines using a “panic” icon on their desktop.

My great-aunt asked for a PC when she was 85 and her grandchild moved abroad. I installed Linux mint with a few scripts and shortcuts to ease her life, and she picked that up (check email, Skype, nothing super sophisticated ofc). I guess if it’s a new thing, windows does not the advantage of being already familiar, and Linux is more stable in my experience, which leads to less random errors.

Yes, it is a metasearch engine. It’s basically like proxy+aggregator or multiple engines.

This statement makes no sense. Federated search means nothing. Ultimately someone needs to scrape, index, store and retrieve data. At the moment, a handful can do it efficiently, and to have a wide coverage, engines use also other APIs. Kagi does this, for example, by combining Google and others (e.g. brave) with their own indexer.

How do you imagine a “federated” search would be any different? Using multiple APIs is effectively “federating”.

As I said in another comment, to be fully ethical you should not run on any major cloud (owned by Amazon, Google, Microsoft, Oracle and IBM), not run on anything on fossil fuels (few DCs), not use any API of major companies (google, apple, etc.) and so on. So basically if we ever want a new, better, solution (tech) we just need to materialize a few billions of dollars to allow this fully ethical solution with no dependency on immoral parties. Alternatively, the whole market dynamic should be disrupted, because that’s the problem.

They are using brave search results, like they do with others. Frankly, you could build totally identical arguments (and to be honest, much more serious) for “partnering” with Google and Microsoft, but then the product wouldn’t exist and wouldn’t be as good.

The relationship with the Brave founder is so indirect, that this - to me - feels like an argument from someone who is looking for reasons to get angry. Kagi probably uses AWS (or other clouds), which funds Amazon (known for terrible worker rights), funds Google, fossil fuel industry, etc. It’s a sad reality, but you simply can’t exist nowadays in the moral and ethical way many people would like. You can, only if you are a privileged one. Technologically speaking, Google can probably do it, for example (own hardware, DCs, tech etc.). We can choose to fight those that directly support political agendas we disagree with, or we can damage the smallest players by demanding they will be 100% pure and ethical by not having any relationship with those with those agendas.

In my personal opinion, such unrealistic ethical requirements end up being a reactionary choice as they will ultimately impede new - better - players to emerge and will leave the existing - worse - dominating.

As I said elsewhere, the company implemented this feature and apparently did not do absolutely jack about the increased risk of account compromise deriving from it. If I would sit in a meeting discussing this feature I would immediately say that accounts which share data with others are way too sensitive and at least these should have 2fa enforced. If you don’t want it, you don’t share data. Probably the company does not have a good security culture and this was not done.

It doesn’t matter. It is a known attack and the company should have implemented measures against it.

At the very least, they should have made a threat modeling exercise and concluded that with this sharing feature, the compromise of a single account can lead to compromise of data for other users. One possible conclusion is that users who shared data should be forced to have 2fa.

It doesn’t matter. It is a known attack and the company should have implemented measures against it.

At the very least, they should have made a threat modeling exercise and concluded that with this sharing feature, the compromise of a single account can lead to compromise of data for other users. One possible conclusion is that users who shared data should be forced to have 2fa.

Companies pay SMS, TOTP is free for them (just a computation…). It is utterly dumb to implement the same logic with a paid service rather than TOTP (or security keys, at this point). So yeah, I agree with the idea, but I think nowadays most 2fa is TOTPs (sadly, some require their shitty apps to do just that - Blizzard once was one of them, maybe still is).

I don’t think it’s possible to make a blanket statement in this sense. For example, Lemmy doesn’t handle as sensitive data as 23andMe. In this case, it might be totally acceptable to have the feature, but not requiring it. Banks (at least in Europe) never let you login with just username and password. The definitely comply with different standards and in general, it is well understood that the sensitivity of the data (and actions) needs to be reflected into more severe controls against attacks which are relevant.

For a company with so sensitive data (such as 23andMe), their security model should have definitely included credential stuffing attacks, and therefore they should have implemented the measures that are recommended against this attack. Quoting from OWASP:

Multi-factor authentication (MFA) is by far the best defense against the majority of password-related attacks, including credential stuffing and password spraying, with analysis by Microsoft suggesting that it would have stopped 99.9% of account compromises. As such, it should be implemented wherever possible; however, depending on the audience of the application, it may not be practical or feasible to enforce the use of MFA.

In other words, unless 23andMe had specific reasons not to implement such control, they should have. If they simply chose to do so (because security is an afterthought, because that would have meant losing a few customers, etc.), it’s their fault for not building a security posture appropriate for the risk they are subject to, and therefore they are responsible for it.

Obviously not every service should be worried about credential stuffing, therefore OWASP can’t say “every account needs to have MFA”. It is the responsibility of each organization (and their security department) to do the job of identifying the threats they are exposed to.

Yes, forced mfa (where forced means every user is required to configure it) is the most effective way. Other countermeasures can be effective, depending on how they are implemented and how the attackers carry out the attack. Rate limiting for example depends on arbitrary thresholds that attackers can bypass by slowing down and spreading the logins over multiple IPs. Other things you can do is preventing bots to access the system (captcha and similar - this is usually a service from CDNs), which can be also bypassed by farms and in some cases clever scripting. Login location detection is only useful if you can ask MFA afterwards and if it is combined with a solid device fingerprinting.

My guess in what went wrong in this case is that attackers spread the attack very nicely (rate limiting ineffective) and the mechanism to detect suspicious logins (country etc.) was too basic, and took into account too few and too generic data. Again, all these measures are only effective against dumb attackers. MFA (at most paired with strong device fingerprinting) is the only effective way there is, that’s why it’s on them to enforce, not offer, 2fa. They need to prevent the attack, not let just users take this decision.

If the accounts were logged into from geographically similar locations at normal volumes then it wouldn’t look too out of the ordinary.

I mean, device fingerprinting is used for this purpose. Then there is the geographic pattern, the IP reputation etc. Any difference -> ask MFA.

It’s so difficult that most companies tend to just defer to large players like Google and Microsoft to do this for them.

Cloudflare, Imperva, Akamai I believe all offer these services. These are some of the players who can help against this type of attack, plus of course in-house tools. If you decide to collect sensitive data, you should also provide appropriate security. If you don’t want to pay for services, force MFA at every login.

Of course this is not a brute force attack, credentials stuffing is different from bruteforcing and I am well aware of it. What I am saying is that the “lockout period” or the rate limiting (useful against brute force attacks) for logins are both security measures that are sometimes demanded from companies. However, even in the case of bruteforcing, it’s the user who picks a “brute-forceable” password. A 100 character password with numbers, letters, symbols and capital letters is essentially not possible to be bruteforced. The industry recognized however that it’s the responsibility of organizations to implement protections from bruteforcing, even though users can already “protect themselves”. So, why would it be different in the case of credentials stuffing? Of course, users can “protect themselves” by using unique passwords, but I still think that it’s the responsibility of the company to implement appropriate controls against this attack, in the same exact way that it’s their responsibility to implement a rate-limiting on logins or a lockout after N failed attempts. In case of stuffing attacks, MFA is the main control that should simply be enforced or at the very least required (e.g., via email - which is weak but better than nothing) when any new pattern in a login emerges (new device, for example). 23andMe failed to implement this, and blaming users is the same as blaming users for having their passwords bruteforced, when no rate-limiting, lockout period, complexity requirements etc. are implemented.

My idea is definitely biased by the fact that I am a security engineer by trade. I believe a company is ultimately responsible for the security of their users, even if the threat is the users’ own behavior. The company is the one able to afford a security department who is competent about the attacks their users are exposed to and able to mitigate them (to a certain extent), and that’s why you enforce things.

Very often companies use “ease” or “users don’t like” to justify the absence of security measures such as enforced 2fa. However, this is their choice, who prioritize not pissing off (potentially) a small % of users for the price of more security for all users (especially the less proficient ones). It is a business choice that they need to be accountable for. I also want to stress that despite being mostly useless, different compliance standards also require measures that protect users who use simple or repeated passwords. That’s why complexity requirements are sometimes demanded, or also the trivial bruteforce protection with lockout period (for example, most gambling licenses require both of these, and companies who don’t enforce them cannot operate in a certain market). Preventing credentials stuffing is no different and if we look at OWASP recommendation, it’s clear that enforcing MFA is the way to go, even if maybe in a way that it does not trigger all the time, which would have worked in this case.

It’s up to each user to determine how securely they want to protect their data.

Hard disagree. The company, i.e. the data processor, is the only one who has the full understanding of the data (sensitivity, amount, etc.) and a security department. That’s the entity who needs to understand what threat actors exist for the users and implement controls appropriately. Would you trust a bank that allowed you to login and make bank transfers using just a login/password with no requirements whatsoever on the password and no brute force prevention?

The fact that they did not enforce 2fa on everyone (mandatory, not just having the feature enabled) is their responsibility. You are handling super sensitive data, credential stuffing is an attack with a super low level of complexity and high likelihood.

Similarly, they probably did not enforce complexity requirements on passwords (making an educated guess vere), or at least not sufficiently, which is also their fault.

Regarding the last bit, it might noto have helped against this specific breach, but we don’t know that. There are companies who offer threat intelligence services and buy data breached specifically to offer this service.

Anyway, in general the point I want to make is simple: if your only defense you have against a known attack like this is a user who chooses a strong and unique password, you don’t have sufficient controls.