HackerTrans
トップ新着トレンドコメント過去質問紹介求人

80x25

no profile record

投稿

Grit

grit.io
1 ポイント·投稿者 80x25·3 年前·0 コメント

CSRFing VS Code's Debug Adapter Protocol

mcnulty.blog
2 ポイント·投稿者 80x25·3 年前·0 コメント

The excellent Arc browser is now available for anyone to download

theverge.com
6 ポイント·投稿者 80x25·3 年前·2 コメント

Hacking Auto-GPT and escaping its Docker container

positive.security
2 ポイント·投稿者 80x25·3 年前·0 コメント

Mark Zuckerberg: “VR / AR strategy” (2015)

techemails.com
1 ポイント·投稿者 80x25·3 年前·0 コメント

Bill Gates Tries to Install Movie Maker

techemails.com
8 ポイント·投稿者 80x25·3 年前·1 コメント

Do Users Write More Insecure Code with AI Assistants?

arxiv.org
1 ポイント·投稿者 80x25·4 年前·0 コメント

Forming a W3C Solid Work Group

lists.w3.org
2 ポイント·投稿者 80x25·4 年前·0 コメント

The Arc browser is the Chrome replacement I’ve been waiting for

theverge.com
3 ポイント·投稿者 80x25·4 年前·1 コメント

Learn to Read the Source, Luke (2012)

blog.codinghorror.com
1 ポイント·投稿者 80x25·4 年前·1 コメント

Dancing in the Debugger – A Waltz with LLDB (2014)

objc.io
1 ポイント·投稿者 80x25·4 年前·0 コメント

コメント

80x25
·3 年前·議論
https://www.mcnulty.blog/

Posts about the Web and the software that powers it. Light on content right now but will hopefully change that soon.
80x25
·3 年前·議論
Interesting idea. I signed up.

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.
80x25
·4 年前·議論
Here's the researcher's write-up of the issue with more details: https://spyclub.tech/2022/12/14/unusual-cache-poisoning-akam...

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.
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.
80x25
·4 年前·議論
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.
80x25
·4 年前·議論
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.
80x25
·4 年前·議論
"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".
80x25
·4 年前·議論
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.