* Posts by KalF

7 publicly visible posts • joined 8 Apr 2020

Australian techie jailed for accessing museum's accounting system and buying himself stuff

KalF

Re: Circular reasoning

yes, they do differ. but Australian govt rules apply for australian security clearance. which was the topic of the study. Although it's relevance to their findings seems limited to amplifying clicky headlines only. They could have reported that 100% of fish n chip shop employees on linkedin appear on HIBP, so you'll get malware with your minimum chips.

in some nation's cases it isnt clearance for a purpose, but rather a general access level. Which is madness IMO, but they seem to make it work.

AGSVA does retain your data so submitting and the initial screening will be faster if you've had it recently. However it is illegal to prefer a candidate on this basis, they must simply be eligible for clearance. But we all know what happens in the real world.

KalF

Circular reasoning

Checking a known breached service (linkedin, pick your recent data breach occurrence) to see if users have had their data breached seems a bit redundant. It's the kind of lazy analysis companies do in order to come up with a headline reason why their staff are better than the randoms on a social network. Anyone using linkedin for longer than a few moments has had their profile exfil'd. Whether that is an actual problem depends on whether they are vulnerable to cred stuffing. Just saying someone appears on HIBP is weak research.

However putting clearance on your profile is a bit off. Clearance is for a specific purpose/role and does not carry to a new role. Hiring only those with current clearance is illegal (AGSVA site explains this quite clearly). And yet recruiters and employers do it all the time anyway. Which is why some are motivated to put their clearance in their profiles. Since what really matters to an employer should be whether clearance is attainable, perhaps candidates should put their citizenship and whether or not they have been to the big house?

It's completely unsupportable. Yes, we mean your brand new system

KalF

I may not have made the 'focus on what is core' part clear. The skills you prioritise should be for your core money making systems. If you allow your back office tech stack to dictate tech choices for your core products you'll have a company that can't compete or evolve.

Your back office is not unimportant and ppl shouldnt draw that conclusion simply because I say it shouldnt drive your tech choices. But efficiency gains should drive the cost and focus down over time for those support systems.

As for deciding what your core systems are, if the CIO and CTO can't decide that, then tech stack choices are the least of your challenges.

KalF

organisations should specialise on what is core to their business. That part should never be outsourced, but everything else either should be completely outsourced or operated in a manner that prioritises a stable and efficient service to the broader organisation. Effectively replicating the benefits of outsourcing, while mitigating the downsides we've all suffered.

Therefore if you innovate within your core business, but prioritise the capabilities within the support arm of the organisation, as appears to be the moral of the story, then you are holding the stick wrong. I think many CTOs and CIOs feel connected to their enterprise backoffice support backgrounds, to the detriment of business value.

There's clearly a balance that must be found, skills and control within your supporting services are important, but its the core business that should drive innovation. In the story in the article, I would have refocused the team on the product platform (assuming those skills werent there to begin with) and thought long and hard about my dependence on skills for 'mainstream' systems that didnt make me any money. They had effectively invested in skills and capabilities that didnt offer a competitive advantage. The good staff will adapt and thrive.

Linux laptop biz System76 makes its first foray into the mechanical keyboard world with dinky, hackable Launch

KalF

ur choice of firmware, but not keycaps?

I can hack the firmware, great, but I will probably never do it.

Can I use custom keycaps with that split space bar tho? There's a community of ppl who do like to change up the hardware of their keyboards, from the switches to the key caps. This appears to service some other non existent community that likes to modify firmware but not much else.

and it isnt quite what most ppl would expect in a TKL keyboard which is 87/88 keys. They have borrowed a key from the bottom right hand cluster you normally have on a TKL for the second space bar. No big deal since that rarely does anything other than RGB profile control. They have also taken 4 keys from the top right cluster where you'd expect PRT, SCR, INS etc.. the reason for that is less clear. if TKL is too wide, use the compact form factor other keyboard providers use.

This is node joke. Tor battles to fend off swarm of Bitcoin-stealing evil exit relays making up about 25% of outgoing capacity at its height

KalF
Unhappy

Re: I continue to be surprised

Plain HTTP can be manipulated to inject exploits. This is why you always need HTTPS regardless of the content on your site. A lot of shopping cart attacks start this way, using unencrypted parts of a site to compromise subsequent encrypted activities.

As others have said, its 2020, certs are free, the software is simple. There's no good excuses anymore for using plain text http, although the bad ones remain.

Something something DANE cook: Microsoft pledges to wrap its email systems in secure anti-snooping protocol

KalF

Not quite right

@bige TLSA doesnt remove PKI to replace it with DNSSEC and root level authority. It uses your proven control of your own domain to tell the client mail server what to expect from the certificate the remote mail server will present _after a secure connection is established_. Bear in mind that all public certificates already rely on proof of domain control in order to issue you that cert. So this is not weaker or stronger, its simply more practical for SMTP. RFC7672 does contain a good intro into why SMTP secure connections dont match the HTTPS paradigms. go check it out if you want to dive into the details.

There is a DNS record that can help with email encryption, but client tools are probably lagging (OPENPGPKEY). The MS announcement doesnt make this easier or harder.

@DrFlay, you may have conflated adoption of mail security with adoption of all possible DANE records. Until browsers come to the party web TLSA records are a novelty. This has no impact on smtp TLSA adoption.