80x25

Posts about the Web and the software that powers it. Light on content right now but will hopefully change that soon.

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.

Interesting research and super useful write-up!

My observations:

- 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.

- 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.

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.

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.

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".

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.

By what measure?

"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.

http://stackoverflow.com/questions/4297014/what-are-the-diff...