Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)L

loudwhisper

@ loudwhisper @infosec.pub

Posts
5
Comments
79
Joined
3 yr. ago

  • Proton’s Lumo AI chatbot: not end-to-end encrypted, not open source

    Jump

  • They actually don't explain it in the article. The author doesn't seem to understand why there is a claim of e2e chat history, and zero-access for chats. The point of zero access is trust. You need to trust the provider to do it, because it's not cryptographically veritable. Upstream there is no encryption, and zero-access means providing the service (usually, unencrypted), then encrypting and discarding the plaintext.

    Of course the model needs to have access to the context in plaintext, exactly like proton has access to emails sent to non-PGP addresses. What they can do is encrypt the chat histories, because these don't need active processing, and encrypt on the fly the communication between the model (which needs plaintext access) and the client. The same is what happens with scribe.

    I personally can't stand LLMs, I am waiting eagerly for this bubble to collapse, but this article is essentially a nothing burger.

  • Tea App A Second Tea Breach Reveals Users’ DMs About Abortions and Cheating

    Jump

  • If I were in the security team of that company, I would never accept ACLs on the bucket as a sufficient compensating control for this risk. Here the best most reasonable would be encryption, which would make the bucket being public relatively unimportant.

    When you are collecting so sensitive data (potentially including personal data of people not using your service), you simply can't even imagine doing that by storing the data unencrypted.

    Edit: grammar

  • why the hell cant men stay out of women-only spaces?

    Jump

  • Because it's unnecessary in almost all cases. So far there is only one community which forbids people to comment based on who they are, but otherwise the rules boil down to standard acceptable behavior according to common sense. It's also a nuisance for users: I am quite sure nobody wants to click several times and be derailed to check rules (on mobile) for every comment they want to write in every post they see on a feed. If this would be expected as standard behavior, I would guess even less interactions will happen.

  • why the hell cant men stay out of women-only spaces?

    Jump

  • Based on the comments here and in the previous similar post I have seen, the vast, vast majority of people (presumably men) highlight how this is a problem of visibility of posts in public feeds.

    It's a tradeoff between having the community public for discoverability and accepting that many people will not check the rules and violate them, some inadvertently.

    The alternative is to make the community private, and accept that women will need to discover a women-relates community by searching for "women", which doesn't seem incredibly unlikely.

    From the sentiments I read, most people wouldn't care at all if the community was private and wouldn't have a desire to "invade" it. I definitely feel part of this group.

    Considering that it's in the interest of the community (apparently) to have only women, I think it's fair to expect the (minimal) effort from future members to look for it (plus advertising it in posts etc.) on them instead of expecting the vast majority of the users (the fediverse is mostly males) to add friction and having to check the rules of every single community of every post they open (now it might be a community, more might come). Yes, community rules are important, but being realistic, if you don't behave like an asshole you don't need to worry about them in 99% of the times.

    However, if this tradeoff is not deemed acceptable, I think there is no point complaining about people "invading" women spaces because it's guaranteed that many people will comment without reading the rules, as I am sure the almost totality of users does all the time. Even without counting the ones who intentionally violate the rule, there is always going to be an organic amount of people who will do so inadvertently.

    At this point I think the tradeoff is so clear, that discussing the topic in such a confrontational way looks more like rage-bait than anything aimed at solving the problem.

  • The challenge of deleting old online accounts | Loudwhisper

    Jump

  • Thanks. Absolutely my experience too. The ones where you can't edit the email I noticed often used the email as username, and probably god knows how bad is the code on the backend.

  • The challenge of deleting old online accounts | Loudwhisper

    Jump

  • Hey, I haven't, but to be honest, the answers I got from most companies showed me that the processes were handled by people who barely understood the legal and technical aspects around data collection (e.g., often support agents were on the other side of privacy@), which means I wouldn't trust them with their answer anyway AND I doubt many of these companies will have effective way to even check that.

    From the data being sold point of view, I think unfortunately it's way more effective reaching out to the few big data brokers to request cancelations or pay one of the companies who offer such service...

  • The challenge of deleting old online accounts | Loudwhisper

    Jump

  • The challenge of deleting old online accounts | Loudwhisper

    Jump

  • Eh, the thing is I made the formal request using data deletion module, but I just assumed that's what the support person asked the development person ("team"), assuming it was not the same person for both!

  • The challenge of deleting old online accounts | Loudwhisper

    Jump

  • Congratulations on completing this!

    I have indeed moved most accounts to individual aliases. I used to use the same username and similar emails (perhaps grouped like shops@mydomain), but I got no benefit and the username allowed unnecessary correlations.

    So alias + random username and I will have much much less trouble in the future. Hopefully!

  • I wonder if this was made by AI or a shit programmer

    Jump

  • You are right and what some people miss is that social engineering being the vector to gain foothold doesn't mean that it was sufficient to allow the breach. Almost always you need some other weakness (or a series of them). Except when the weaknesses are so had that you don't need a foothold at all (like this case), or when the social engineering gives you everything (rare, but you might convince you someone to give you access to data etc.).

    A whole separate conversation is deserved by how effective (or not) social engineering training is. Quite a few good papers about the topic came out in the last fee years.

  • Rule34 blocked the UK entirely rather than comply due to the new law.

    Jump

  • Social/Political problems need social/political solutions, not technical solutions.

  • If you want to see my pusswatcha, dress like men in hair metal bands from the 1980s.

    Jump

  • This also takes away agency from people. In fact, I am sure that there would be a way to diagnose every single relationship ever as a form of abuse in which someone takes advantage of someone else's something.

    Adults are responsible for their choices, and particularly in the case of "assholes", that is often associated with being assertive, dismissive and some people just like that kind of "I am the main character" features. Maybe there are even some deep rooted evolutionary reasons for that, I don't know. Anyway, painting anything as victim-oppressor dichotomy IMHO is nonsense.

  • Using Clouds for too long might have made you incompetent

    Jump

  • When they need, they'll learn.

    100% agree. But. If you are a principal engineer claiming to have experience hardening the thing, you would expect that learning to have already happened. Also, I would be absolutely fine with "I never had a chance to dig into this specifically, I just know it at a high level" answer. Why coming up with bs?

    Maybe those engineers were like that too.

    I mean, we are talking about people whose whole career was around Kubernetes, so I don't think so?

  • Using Clouds for too long might have made you incompetent

    Jump

  • I partially agree, but not only we are looking for experts of that thing, we are also looking for security experts, and security knowledge is very much meta-knowledge. A software developer might not care at all about - say - how the CI/CD works, because all they care is that the thing builds the code. A security expert generally has a broader scope, and their job is not functional, which means their job is exactly understanding the thing to be able to model the risks around it. So they might not care of all the tools used in that CI/CD or the exact details of the steps, but they should understand the execution flow, the way third party dependencies are pulled, verified, consumed, the authorization model etc.

    There is no such thing of security professional who doesn't understand - at least from an academic point of view - the overall setup of a thing they worked with.

    If I take the image attestation example I made in the post, I consider the "inner workings" to be the cryptographic details, such as ciphers and their working mechanisms, or the exact details of the way that attestation can be verified offline, or what exactly is computed and how. I am OK with someone not knowing this. But not understanding the whole flow? Well, without this what's left? Copying the 3 lines of code that do something from the Github documentation? Any software engineer can very much do that, what is your contribution as a security specialist?

    …..people lie on CVs and cover letters. If your ad has buzzwords and technology X, Y, and Z

    Totally agree. It is very likely, although the more people I interview, the more I think that they are not lying from their perspective. It's that people can legitimately make a career today by stitching together stuff with scotch tape, spending years by just by doing that and effectively have little to show for those years. But from their perspective, they might be experienced in that stuff, maybe?

  • Using Clouds for too long might have made you incompetent

    Jump

  • I wouldn't say it's a large expansion of skillset, meaning it's not massive. But yes, indeed it is problematic to find people. It is because this is a vicious circle in which companies are digging their own graves by eliminating a market for those people, which in turn means that those who would want to hire some can't find them easily, leading to outsourcing instead. Do this for 15 years across the whole industry and it stops being an option, which is pretty much where we are today. That said, training and upskilling is always a possibility for companies who invest on their own employees and are playing the long game...

  • Using Clouds for too long might have made you incompetent

    Jump

  • Well, for the relatively small sample of Kubernetes experts I interviewed, basically any topic beyond "you use this tool" was a disaster, including Kubernetes knowledge. I am not selective, it's not like I expect a specific skillset, but what would you think if someone with a decade of platform security doesn't understand cryptography and supply chain, Linux permissions, Kubernetes foundational concepts, container isolation or networking? At some point the question is legitimate, what are you expert in? The answer I have been able to give myself so far is "stitching together services that do stuff" and "recommend what the documentation/standard recommends". I consider myself satisfied to have somewhat decent knowledge in some of those areas, I am not expecting someone understanding all of that, but none of them? Maybe from someone who just joined the industry.

  • Using Clouds for too long might have made you incompetent

    Jump

  • You say "incompetent" and "less skilled" as general statements on senior engineers. Those statements are false.

    I am saying that the competencies of people who grew up (professionally) with outsourced services are more superficial and give them way less understanding (and agency) on the systems they oversee. I make the opinionated argument that knowing which service to use in a cloud provider is not just a different skill from implementing that functionality "manually", but is hierarchical inferior, easier to acquire and less useful in general.

    A weird parallel would be someone who hikes 100% of the time with a guide who takes care of orientation, camp setting etc., and someone who goes alone. If I am simply comparing the pictures they are showing me, I might not appreciate the difference, but if you asked me who I would trust to come hiking with me, I wouldn't have doubt, because I consider the skill "finding, choosing and listening to the guide" to be hierarchial inferior to "orient, set camp etc. by yourself".

    So it's not just a matter of matching the skills I need, is actually a much broader argument about deskilling engineers.

  • Using Clouds for too long might have made you incompetent

    Jump

  • It depends. An EKS cluster can cost easily 20x what an equivalent cluster costs with same resources. The amount of people necessary to manage it is very close compared to a bare cluster, which depending on the scale can save hundreds of thousands or millions per year, therefore allowing extra headcount.

    For example, a company I worked for had a team of 6 managing all their kubernetes cluster on rented dediservers. The infra costed around 50k/year. The same clusters on EKS could be managed by 4 people (maybe?), but would have costed easily 5-600k, especially since they were beefy machines, possibly even more. That amount of money would pay for 7-8 additional headcount in local hires.

    Considering that in those clusters there were 40-50 postgres clusters, if moving those to RDS they would have probably looked at millions in cloud bills per year, and the effort to run those dB's once the manifests were developed was negligible (same team was managing them). This was a tiny startup, with limited resources for internal tools and automation development.

    So it's not like managing everything can save headcount, it's that not outsourcing everything can save so much money that largely compensates for more headcount, plus you are giving money to real people, who spend local and pay taxes.

  • Using Clouds for too long might have made you incompetent

    Jump

  • But you know what the kernel is. You know that syscalls are a thing, you know what role the kernel performs, you know that different filesystems have different properties (and pros and cons), etc..

    You don't need to know the details, perhaps, but you can't ignore the fundamental theoretical concepts of kernel and OS. You might not know the whole detail of the boot procedure, but if your machines are stuck on boot, you know at least what to look for.

    Here I was talking about equally foundational topics. There is nothing "above" - say - producing attestations and then verifying them. That's literally all there is to it, but if you don't understand the theory behind it, what exactly are you doing? As as I said, I don't care about the details, I didn't expect someone mentioning ciphers or timestamp authorities, transparency logs etc. All I would expect is "we produce a signature with a bunch of metadata and we verify it where we consume the artifact, so that we are sure that the artifact has the properties attested by the signature".

    Not knowing this is like someone claiming that they administer Linux machines but can't explain what network interfaces are or how routing is determined. This is not a question of being expert on different layers, this is just being oblivious to those other layers completely.