Can somebody explain what the optimizations are that this enables?

Of course you can optimize away the checks but that doesn't count in my world because people put in these checks to make sure there is no overflow and optimizing them away is just wrong.

But I am sure there are other interesting optimizations that this allows and since I am generally against UB I am curious what those are.

Wait you cannot hide posts without logging in? What?

I'm confused by that cookie banner. Is it a joke or not? What do you mean by "Do you consent to sharing cookies?" are sharing cookies a special kind of cookie or do did you just mean storing cookies?

The worse part of those banners are that you select "Don't Consent" and then still have to untick all those "Legitimate Intent" options.

Haha :D yeah, it is a joke/pun on cookie consent banners.

The personal problem I have with cookie banners is that in order to _not consent_ they store a local cookie to not display the banner.

And the assumption of consent is by default, which is the exact opposite behaviour of what GDPR expects you to do. Nobody can consent by default to anything, that's the foundational basis of law in the EU.

I'm not using cookies for anything on my website, so there's no point in storing cookies. The Do Not Consent game is for people that want to play off some steam.

Please no. The site is an important resource for people learning JS and other web technologies and AI is great at explaining code snippets which would otherwise be follow-up look-ups and at explaining what the often very dense MDN content means. And AI is actually really good at generating code as well, you just have to review it like it was written by a junior dev.

I think most of the hate for current AI tools comes from the fact that people expect the computer from Star Trek which always provides perfect answers.

Edit: So yes, it needs to be made super obvious to users that it might give you wrong answers.

Except it gets mostly everything wrong, even very simple things that are on the page itself.

https://github.com/mdn/yari/issues/9208

I'm really not sure how you can argue that "AI is great at explaining code snippets" while also acknowledging that it will just give you flat out wrong answers some times.

Either it's good at explaining and is right, or is bad at explaining and is wrong.

Applying the logic of it being "right most of the time" seems really bad for a tool applied to a reference documentation website.

Sorry, if that wasn't clear but I think MDN is not only reference documentation. I agree, for the reference part the AI shouldn't do more than trying to point you to the right parts of the text. But for learning things, nice explanations, even if sometimes slightly off, can be a lot better to digest than reference documentation.

I'm not saying it's great yet, but there is potential for having something that can hand-wave away some details like a human would when explaining something to a beginner.

I think the most important point is, that this solution requires a way to securely transmit the generated link. As described in another comment by @ryandvm this has two advantages over transmitting the password directly: 1. It won't show up in logs or be otherwise accidentally stored. 2. If the link expires after a single use you get security in the covert model. However, this comes with problems because some tools like virus scanners automatically hit links.

Exactly exactly. I made sure to be resilient to Google bots/Virus Scanners by doing some fancy javascript tricks

I don't understand how this relates to the original post. ShareLock is not end-to-end encrypted.

It solves the issue of secret-sharing much better than any of the other proposed solutions here, including InstaPass. You can post the URL in a public channel with confidence, as even if an attacker accesses the URL, they have to verify themselves with their social identity to decrypt the data.

But yes, it's not end-to-end encrypted, so you're better off self-hosting your own instance of sharelock.

I don't understand the threat model here. The link needs almost the same kind of protection as the original password. The only difference is, that the link expires.

So how do you transmit those links securely and why didn't you use that for your passwords in the first place?

I think the key is that the message would be deleted by the server after ONE use. So... you send the link via whatever mechanism you want (Slack, SMS, email, etc.). If a man-in-the-middle intercepted it, they need to follow the link to decrypt it, thereby expiring the message. So if the recipient gets a dead link, then you know security has been compromised.

The main issues here are:

* You have to trust the client implementation to not surreptitiously record the one-time key (for both sender and receiver).

* You have to trust the site operator to actually expire the message after one use.

* Whatever secret you are transmitting MIGHT get intercepted, but at least you would know about it.

I briefly toyed with the idea of creating almost the exact same service - even down to using the URL hash to hide the secret. But at the end of the day, the concept has too many flaws for the security conscious and is too annoying to use for the layman.

Do people not mind the paywall or do you just not get it?

1. Why is parsing a tree which is encoded in JSON easier? 2. Why does it matter if an element is in an attribute or in child elements. You need some kind of schema anyway, right?

It depends on the API of the system. I’ve worked on middleware that would not be able to get an attribute, it lacked the capability. Other systems used JavaScript and it was much easier with JSON

See this link on stack exchange[1].

[1] https://stackoverflow.com/questions/17604071/parse-xml-using...

> //Gets Street name xmlDoc.getElementsByTagName("street")[0].childNodes[0].nodeValue;

I’d much prefer something like jsonObj.address[0].street;. Personally I like to work with objects over parsing documents trees.

The author makes a case for why it would matter:

> XML, on the other hand, optimizes for document tree structures, by cleanly separating node data (attributes) from child data (elements).

Unfortunately, there appear to be some implementation issues here. You have to create a string version of your data to store them in attributes.

So, you lose a bit of context in the conversion.

Such as:

`<Document text="true" />`

Is the text attribute the word _true_ or a boolean _true_. Without referencing some other piece of code or definition there is no way to know.

Whereas in JSON, this wouldn't be necessary, as you can simply remove the quotes and infer that it is not a string, but a boolean.