I used to do that too, but now I go to my spam folder and grab the latest phishing email and use the reply-to address. I like the idea of some sales guy following up a lead with a Nigerian scammer, but sadly I’ll never see the email exchange.
Put such a sales person into the shoes of the Nigerian scammer, uh, I mean "prince" and they might just as well become the Nigerian scammer. It takes a specific kind of person to engage in the dark patterns stuff and be convinced of themselves doing nothing wrong.
Who considers them politically suspect? I’m guessing the people who live in the countries that use them don’t, and on the contrary would increasingly be seeing the USD as politically suspect.
The people who live in the countries that use them aren't relevant, because we are talking about them as reserve currencies. What matters is whether other countries see them as politically suspect.
Where in the discussion or article was the affiliation or relevance of the western political spectrum mentioned? Seems pretty gullible to insert your own frame into a discussion as a gocha towards political opponents you created inside your head.
It's primarily this. I'm a novice Rust developer and really would like to improve the code quality across the board, and some of this comes to attracting the right kind of developers to help. Maybe "Rust" in the title helps, maybe it doesn't. Clearly HN doesn't like it and that's okay.
I stated my need for help on the about page as well
> This is my first Rust project, and it shows. There are bugs, rough edges, and architectural decisions that could be better. I’m documenting the known issues openly because I want everyone to understand what they are getting into, and encourage improvement in the project.
> Maybe "Rust" in the title helps, maybe it doesn't. Clearly HN doesn't like it and that's okay
HN definitely likes it, when it is used in the correct context. Using Rust in the title is a soft promise for better reliability and quality for the software than on average. But it starts to get controversial when Rust is not purely the controlling part of the software anymore. So people start to complain because it can be misleading marketing which is based on the promise that Rust can offer.
Fair enough, most of the critical code in this case is written in Rust. A Rust transcription library popped out of the project `transcription-rs`. And there is a real-time audio library I'd like to put out which allows for filters. I could have called out to ffmpeg or similar, but I chose to implement an audio pipeline myself (for better or worse)
So makes sense, but there are benefits to writing a desktop application backend in Rust for the ecosystem as well.
I'm not the person you replied to, but in a 110 km/h (70 mph) zone you'd get away with just a fine in Australia if caught/pulled over. To lose your license for six months, you'd need to be doing 130+ km/h in an 80 km/h (50 mph) zone.
Yep, I was referring to the license suspension for 6 months though, which is what the earlier post was talking about. What you’re referring to is a license suspension for 3 months.
> SOC 2 is a security and compliance framework created by the AICPA
How is it that a group of accountants (the American Institute of Certified Public Accountants) was able to create a security framework for software, and position themselves as the sole gatekeeper who decides which auditors are allowed to certify SaaS vendors?
I’m surprised that companies would look to accountants, rather than people from the tech industry, to tell them whether a vendor has good IT security practices.
Yet the whole tech industry seems to be on board with this, even Google, Microsoft, etc. How did this come to be?
It's an audit standard about security. It's not a security standard. It defines a small number of extremely broad goals, like "you do risk management" and "you have access control mechanisms", which might be IT tools or might be a tabletop RPG.
You're irritated that people keep describing it at a security standard, which is understandable, but it isn't. AICPA auditors run SOC2 audits because SOC2 is an audit; it's about reconciling paperwork and evidence, about digesting policies and then checking that you actually do anything in those policies.
If you want to know about a firm's actual security program, you'll need to ask deeper questions than SOC2 can answer.
When I worked someplace undergoing a SOC2 audit I had to periodically jump into calls with our auditor and security architect to answer all sorts of highly-specific questions about how we deployed our software and the infrastructure that it ran on. At one point, for instance, the auditor told me that they needed me to demonstrate that our servers were all configured to synchronize their clocks to an NTP server. Kubernetes was a foreign concept to them and pointing to GKE docs wasn't sufficient - if memory serves I had to MacGyver some evidence together by hacking a worker node to be able to get a terminal on it and demonstrate that, yes, Google's managed VMs indeed run chronyd.
This seems to be the opposite of
> It's not a security standard. It defines a small number of extremely broad goals
Is this because of the specific auditors we were using? Are some more sympathetic than others to contemporary engineering practices?
Yes, and yes. No matter how good your auditors are, unless you're accepting a shrink-wrapped set of controls from a tool provider like Vanta, you need to be pushing back on things they demand; you just have to have a clear idea of what the Common Criteria control they're looking for is (you'll see this clearly from the DRL they give you at the start of the engagement), and then when they ask for stuff that doesn't matter or isn't relevant for your org, you explain how what they're asking for has nothing to do with the actual control you're working on.
So far as I can tell there is almost nothing that is a firm requirement in a standard SOC2 Security TSC audit. We even got "background checks" rolled back.
Our audit firm is a SOC2 practice that informally spun of out of a Big 4 firm. When people get audits after using GRC tools like Drata, they often get matchmade to auditors who bid down the cost of the audit. It's possible that one of the things you get when you pay low-mid 5 figures for an audit instead of low-mid 4 figures for an audit is a lot more flexibility and back/forth with the auditors; I don't know. If that's the case: pay for the better auditors. These are rounding error expenses compared to doing extra engineering work just for SOC2.
In my experience, it's more likely it was the approach of the folks at your company that made your controls.
SOC2 (and a bunch of similar regimes) basically boil down to "have you documented enough of your company's approach to things that would be damaging to business continuity, and can you demonstrate with evidence to auditors with low-to-medium technical expertise that you are doing what you've said you'd do". Some compliance regimes and some auditors care to differing degrees about whether you can demonstrate that what you've said you'd do is actually a viable and complete way to accomplish the goal you're addressing.
So the good path is that the compliance regime has some baseline expectation like "Audit logs exist for privileged access", and whoever at your company is writing the controls writes "All the logs get sent to our SIEM, and the SIEM tracks what time it received the logs, and the SIEM is only administered by the SIEM administration team" and makes a nice diagram and once a year they show somebody that logs make it to the SIEM.
One of the bad paths is that whoever is writing the controls writes "We have a custom set of k8s helm charts which coordinate using Raft consensus to capture and replicate log data". This gets you to the bad path where now you've got to prove to several non-technical people how all that works.
Another bad path is that whoever writes the control says "well shit, I guess technically if Jimbo on the IT team went nuts, he could push a malicious update to the SIEM and then log in and delete all the data", and so they invent some Rube Goldberg machine to make that not possible, making the infrastructure insanely more complex when they could have just said "Only the SIEM admins can admin the SIEM" and leaned on the fact that auditors expect management to make risk assessments.
The other bad path is that whoever is writing the controls doesn't realize they have agency in the matter, and so they just ask the auditors what the controls should be, and the auditors hand them some boilerplate about how all the servers in the server farm should run NTP and they should uninstall telnet and make sure that their LAMP stack is patched and whatever else, because the auditors are not generally highly technical. And the control author just runs with that and you end up with a control that was just "whatever junk the auditors have amalgamated from past audits" instead of being driven by your company's stack or needs.
Similarly, I've had many instances where an auditor would ask for X and instead of trying to show them X I would instead ask them what control / Common Criteria item they were trying to get assurance on. So much of the process is about educating the auditors about how your systems operate and how you manage risks, rather than just trying to provide or build anything and everything they ask for.
*X = password expiry configuration, server antivirus, approval emails, etc.
> "whatever junk the auditors have amalgamated from past audits"
At a large financial company, I was tasked with gathering some audit data to evidence that only certain people could access certain things. To do that, we had to get the list of users with access.
The access control tool at the time used plain text files. I sent the plaintext file with the list of names to the auditor. The auditor said that won't do, because it could have been forged. That's fair.
After lots and back and fourths, the solution was that I needed to send over a screenshot of a terminal window with a list of names, because that's what the auditor expected, and that's what had previously been submitted.
Not a screenshot of the actual document. Not a terminal showing the hostname or similar on the server. I had to get the textfile I'd sent, open it in vim, take a screenshot of vim, and submit that.
Most of the bad paths are usually taken by engineers with little or no experience being audited. After going through the ringer a few times (learn not to answer questions that aren't asked, or that they have a say in what that control should be) the pendulum swings in the other direction, where the answers are always good-path, not necessarily the real-path. At least until the practical part of the audit starts to look at what they really do, not what they say they do.
There's another giant pothole to navigate in many organizations, related to this:
> when they could have just said (...) and leaned on the fact that auditors expect management to make risk assessments
When management has decision paralysis and fear of accountability the engineers feel the need to compensate for the tight spot and solve problems the way they know how to solve them. With technical measures. And a technical measure that fixes the organizational problem tends to be complex and fidgety. Doubly hard for the auditors to properly take in.
“Management” here is a term of art. For many compliance regimes and controls, the engineer responsible for a system can make a statement as “management”.
> Kubernetes was a foreign concept to them and pointing to GKE docs wasn't sufficient
This doesn’t surprise me one bit, in my case our auditors didn’t have a clue what GitHub was and we had to explain how code reviews and deployment pipelines worked. And these are the people who are tasked with certifying whether we’re doing our job correctly.
Sure, maybe it’s because we didn’t pick good auditors. But the accountants certified those auditors, and the whole point of certification is that we can rely on it to establish basic knowledge.
You're relying on their ability to review documents and the meaningfulness of the reputation they stake on a signature saying they actually reviewed those documents. Nobody who has been through a SOC2 audit would ever reasonably think you're relying on your auditor's technology skills.
I've always viewed SOC-2 as a certification for business continuity, not security. Once you view it as making sure that the service can continue running, even with disaster or heavy turnover, it makes more sense.
Because CS refuses to formalize/unionize/license itself to its own detriment. There is no standard software developer. Accounts have some minimum bar to maintain their license. Who would you choose?
I followed the links to the study they referenced, and it says:
> Unlike the camera and audio APIs, the APIs for taking screenshots and recording video of the screen are not protected by any permission
However they also talk about doing static analysis on 9,100 out of the 17,260 apps, to determine (amongst other things) “whether media APIs are actually referenced in the app’s code”.
They then talk about doing a dynamic analysis to see which apps actually call the APIs (rather than just link to a library that might call it, but the app never calls that function the library).
The soundbite is bad, it shouldn’t say “had potential permissions to take screenshots”, it should just say “had the potential to take screenshots”
Where I live, and it seems in most places in the world, a standard drink is 10g of alcohol.
> The definition of what constitutes a standard drink varies very widely between countries,[2] with what each country defines as the amount of pure alcohol in a standard drink ranging from 8 to 20 grams.
> The sample questionnaire form for the World Health Organization's Alcohol Use Disorders Identification Test (AUDIT) uses 10 g (0.35 oz),[3] and this definition has been adopted by more countries than any other amount.
One problem with the idea of a “standard drink” is that what people typically get at a bar (eg a pint of beer) is actually a fair bit more than a standard drink. It’s unrelated to a typical pour.
They emailed us in advance of the update being pushed out saying it would lower battery life, and offered compensation options ahead of time. It wasn't reactionary. If it were a buggy update the email wouldn't come before the update.
Like I said, they emailed us ahead of time and THEN pushed the update. Before the update was pushed, they said the battery life would deplete and offered compensation options.
They haven't said why they did this, like if it was a battery defect issue or what.
reply