I noticed that the email confirmation links are using http:// vs. https://. Chrome has started to flag http:// links with a full-page speed bump, saying it is insecure. Perhaps those links should use https://?
I did try manually switching to https:// in the URL but Chrome didn't like the cert there either.
- The characters that enable the Host header field forgery aren't unicode characters. They are a subset of separator characters from ASCII. My guess is that the Akamai parser is trimming the Host header field name and not enforcing the requirements from https://www.rfc-editor.org/rfc/rfc7230#section-5.4 after this trim, specifically:
A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.
Even worse, the last Host header field appears to "win" and be the selected Host header field in the request forwarded to the origin.
- The OP does mention that Akamai intends to enable stricter header field parsing in 2023 but that response leaves a lot to be desired. They could probably provide a proactive analysis of a customer's traffic to inform them that they can turn on RFC compliant parsing without impact. Punting this decision to their customers requires their customers to be HTTP experts. If I were an Akamai customer, I would expect them to be my HTTP experts for me.
This is spot on. I'm very glad to see this post mention the "No Silver Bullet" essay. Despite being written in 1986, it continues to provide a relevant, skeptical view on the impact of these LMMs on software. It even has a section addressing whether AI can provide the "silver bullet", which is drawn upon by the OP.
My immediate response to all the rightly-deserved excitement for ChatGPT is to reread that essay and reflect on whether this new tool will provide me more than marginal gains in my productivity. Experimenting with it a bit over the last day, my initial answer is, no, this doesn't provide more than marginal gains outside toy examples.
These tools may very well factor into my workflow in the future, but I don't see them fundamentally changing the way I construct, support, debug, and maintain software.
I find myself returning to this blog post about once a year. It think it has aged pretty well in the decade since it was written.
One thing that definitely did not pan out is being able to understand the source of a website/web app because it is written in JavaScript. Transpiling/minification/etc. without the corresponding source maps makes that near impossible for any app of a reasonable size.
"Use OSS" is very close to if not the same as "Build".
To adopt an OSS approach for SSO, the startup still needs to dedicate resources to researching the OSS options, deploying the OSS, integrating it, and most importantly, operating it.
Once the startup gets into the weeds of integrating SSO functionality with customer's IdPs, in the limit, the cost of the effort will start to approach "Build".
This post seems to suggest that a SaaS startup would consider creating their own SAML implementation. If a SaaS startup is considering creating a homebrew SAML implementation, they are doing it wrong.
When it comes to SSO, "buy" instead of "build", and focus on the core value proposition of the service with that saved time and resources.
The rust+wasm story is quite nice these days. I've been working on a rust+wasm SPA for a few months and I have yet to run into issues with the tooling (wasm-pack, wasm-bindgen, etc).
Perhaps your comment was meant to be tongue in cheek, but it sounds like this data exchange is a replacement for the World Wide Web? It's not IPFS is it?
These mitigations feel like a half measure. To quote the Spectre paper:
"Even code that contains no conditional branches can potentially be at risk."
"long-term solutions will require that instruction set architectures be updated to include clear guidance about the security properties of the processor, and CPU implementations will need to be updated to conform."
It seems too early to declare Spectre class attacks mitigated by the mechanisms presented in the OP.
The issue with that approach is that it allows man-in-the-middle attacks, because all of the characteristics you are suggesting the browser validate can be faked if the root is untrusted.
"But there are some imperfections still, especially around tty's an the vt100. My beloved byobu, screen, and tmux don't quite work yet, but they're getting close!"
If they actually fix these imperfections, that would be fantastic. It would address a number issues that are "unfixable" in Cygwin flavors of utilities/apps.
Posts about the Web and the software that powers it. Light on content right now but will hopefully change that soon.