TekMol

Votes are crucial. HN goes to great lengths to prevent votes that do not stem from real user intent.

See this post for example:

https://news.ycombinator.com/item?id=22761897

Quotes:

"Voting ring detection has been one of HN's priorities for over 12 years"

"I've personally spent hundreds of hours working on this"

Nope, it would not have been prevented by CORS.

CORS prevents reading from a resource, not from sending the request.

If you find that surprising, think about that the JS could also have for example created a form with the vote page as the target and clicked on the submit button. All completely unrelated to CORS.

The same would have worked with a POST endpoint.

The story url only would have to point to a web page that creates the upvote post request via JS.

So why is there no problem with vote/flag/vouche on HN being GET endpoints?

If you rely on the HTTP method to authenticate users to mutate data, you are completely lost. Bots and humans can send any method they like. It's just a string in the request.

Use cookies and auth params like HN does for the upvote link. Not HTTP methods.

What's your problem with it?

Can you give an example of an endpoint where you would prefer a "RESTful API endpoint"?

You know what type of API I like best?

    /draw_point?x=7&y=20&r=255&g=0&b=0
    /get_point?x=7&y=20
    /delete_point?x=7&y=20

Because that is the easiest to implement, the easiest to write, the easiest to manually test and tinker with (by writing it directly into the url bar), the easiest to automate (curl .../draw_point?x=7&y=20). It also makes it possible to put it into a link and into a bookmark.

This is also how HN does it:

    /vote?id=44507373&how=up&auth=...

No matter if the LLM is on the same machine or elsewhere, why would you need WASM to talk to it and not just JS?

Sure. You brought up Dropbox. Not me.

It seems the only code that runs in the browser here is the code that talks to LLMs on servers.

Why would you need WASM for this?

That's basically how the File System Access API works, yes.

Technically probably not completely "without restriction". But for all practical purposes, it works just fine for me.

As far as I know, Dropbox does not merge data.

I never tried it, but from the descriptions I have read, Dropbox detects conflicting file saves (if you save on two devices while they are offline) and stores them as "conflicting copies". So the user can handle the conflict.

As a developer, you would do this in the application. "Hey, you are trying to save your data but the data on disk is newer than when you loaded it ... Here are the differences and your options how to merge.".

What do you mean by "storage target"?

Since the File Access API lets web apps simply use the file system, I guess you could just write the file to a shared drive.

One approach might be to save the file to a shared drive like Google Drive?

Do we still need a back-end, now that Chrome supports the File System Access API on both desktop and mobile?

I have started writing web apps that simply store the user data as a file, and I am very pleased with this approach.

It works perfectly for Desktop and Android.

iOS does not allow for real Chrome everywhere (only in Europe, I think), so I also offer to store the data in the "Origin private file system" which all browsers support. Fortunately it has the same API, so implementing it was no additional work. Only downside is that it cannot put files in a user selected directory. So in that mode, I support a backup via an old-fashioned download link.

This way, users do not have to put their data into the cloud. It all stays on their own device.

Currently, what I do is that when an IP requests insane amounts of URLs on my server (especially when its all broken urls causing 404s) I look up the IP and then block the whole organization.

For example today some bot from the range 14.224.0.0-14.255.255.255 got crazy and caused a storm of 404s. Dozens per second for hours on end. So I blocked the range like this:

iptables -A INPUT -m iprange --src-range 14.224.0.0-14.255.255.255 -j DROP

That's probably not the best way and might block significant parts of whole countries. But at least it keeps my service alive for now.

What do others here do to protect their servers?

    solve the DNS auth hurdle, not the
    overall expiration hurdle

That would already be a big step forward.

If the owner does not find out that someone got control of their DNS server, the attacker can do anything with the domain anyhow. Including issuing certs.

> An attacker should not gain the ability to > persistently issue certificates because they > have one-time access to DNS.

They wouldn't. As soon as the owner of the domain removes the TXT entry that ability would be gone.

You now have described the status quo in length. But you have not touched on why it is supposed to make sense. You have not provided attack vectors for the easier alternatives.

    By uploading a file to tekmol.freewebhost.com,
    you haven't proven that you control either
    .freewebhost.com

Who said that putting a file on a subdomain should grant you a cert on the domain? Putting it on domain.com/.well-known/acme-challenge/ should.

Certificates are still a pain in the butt. One of the most cumbersome aspects of the web.

Especially domain wide certs which need DNS auth.

DNS auth would be okish if it was simply tied to a txt entry in the DNS and valid as long as the txt entry is there. Why does LetsEncrypt expire the cert while the acme DNS entry is still there? Which attack vector does this prevent?

Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?

The screenshots... wow!

To me, Mac OS X looks so much better than todays Mac OS. It looks clear and orderly and I feel like "Great in this environment I can get some work done!".

Current Mac OS feels like "Help, I fell into a sack of candies, how do I get out of here?" to me.

Does anybody else feel like that?

Speaking about batteries ... is it dangerous to keep old phones around?

Could their batteries start to burn at some point? I mean when not using the phone at all, just keeping it in a drawer, turned off.

    Debian will remove code that “calls home”
    or tries to update software in a way that
    bypasses the Debian packaging system.

Thank god. I'm so happy that such a distro exists.

Their first example is about having to have a try/finally block in a function like this:

    function processData(response) {
        const reader = response.body.getReader();
        try {
            reader.read()
        } finally {
            reader.releaseLock();
        }
    }

So that the read lock is lifted even if reader.read() throws an error.

Does this only hold for long running processes? In a browser environment or in a cli script that terminates when an error is thrown, would the lock be lifted when the process exits?

Shouldn't this be "imap to sqlite" or something? Why tie it to one specific email provider?

So how much faster than JS is Wasm for typical use-cases?

You can use fixed data structures like Uint8Array in JavaScript just like you can (have to?) in Wasm. Then you won't have the GC do stuff, right?

Interesting. Really an order of magnitude?

What types of operations are 10x faster in Wasm than in JS? Why can't the JIT compiler compile JS to the same native code as your Wasm gets compiled to?