@manton Notes requests:

1. Ability to customize the "This is a private note that has been shared" text for localization and other purposes.
2. When a note has been unshared or deleted, throw up a "this note has been removed" page instead of the generic 404.

I already see how I'll use notes and am excited to fully dive in.

@Mtt Thanks! Can you explain more about why a custom 404 for deleted notes is important?

@manton I'd prefer it not register as a 404 at all. For me, notes are more disposable than pages/posts. If I delete a page or post, a 404 is the right way (for many reasons). But if I delete a note (that is often temporary by design), I'd prefer it be indicated that way on the page. Wording similar to "The private note you're attempting to access is no longer available."

@Mtt @manton Given the Notes feature's focus on encryption and privacy, I would recommend against introducing extra metadata like this. Not everyone might want the world to know that they previously had a note published at a certain URL. For plausible deniability.

If Micro.blog leaks the information "there was a private note at this URL in the past" – attackers and bullies might exploit that in different ways. For example, a bully that wants to perform a character assassination on a blogger could author a nefarious post like "Hey, I just read Joe's note here (since deleted) where he wrote [insert false statement here]." and link to a deleted note that actually said something entirely different. If Micro.blog were to leak that there actually was a private note there in the past, it would add credibility to the bully's post.

There might be other scenarios where an attacker could be helped by knowing a note existed in the past. Generally, you want to leak as little metadata as possible when dealing with secrets and semi-secrets.

@sod @manton +1 to all @sod said.

@sod @otaviocc I understand that side, but if you make the note shareable, you’ve given up any expectation of privacy and encryption. No password is required, no encryption key, no email verification. The only barrier is knowledge of the URL. Unless I’m missing something?

An example: in Apple Notes, once you share a note, you can no longer password protect it. Sharing removes privacy by default.

@Mtt No, you're not missing anything, the encryption ends when a note is shared. Apple Notes is a great example, they take this precaution as well. Try stop sharing a note in Apple Notes and then visit its URL, you won't see "there was a note here previously". Instead, you're presented with a login screen. The same is true for paths that never existed, like https://www.icloud.com/notes/Micro.BlogExample. There's no way to tell an old note URL from one that never existed.

@sod @manton But it’s not a 404. That’s my main angle on this. By clicking that link and getting the login screen, you know (as you were alluding to earlier) that something was there.

Perhaps there is a middle ground here?

In the grand scheme of things, it’s probably nit-picky.

As a side note, if privacy and encryption are the primary goals, I think it needs FaceID enabled on iOS in the app. And possibly a pin (with auto timeout) in the browser. For me personally, I don’t feel I’ll use it for private info, but if others are…

@Mtt Yeah, I don't have an opinion about the actual HTTP status code. It could be whatever. As long as there's no way for an attacker to tell if there's been a note at a certain URL or not, like in Apple's case, I'm happy. 😊

@otaviocc @manton @sod also co-signed

@Mtt Here's part of the definition from the RFC:

The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists.

I wouldn't say it's the equivalent of failure, a resource can have gone missing mistakenly or have been deliberately deleted. Or it might have never existed in the first place (a mistyped URL). Avoiding broken URLs is a noble cause and something I strive for myself. But when something is gone for real or never existed in the first place, 404 (or 410) should be returned by the server so that humans and robots, like search crawlers, can take necessary actions.

@sod @Mtt Thanks for the thoughts on 404s. Seems best to keep the current behavior for now. I appreciate the discussion, though, because I might miss something… The security of this is a new thing for us.

@Mtt Face ID and/or a pin was something @vincent suggested too. Personally, I don't like it when an app forces that on me, because I already consider my phone secure just to unlock it. It is on our to-do list to consider later, though.

@manton I actually agree with you there for how I use my devices. But there are others who share devices or aren’t as conscious about it who may need the extra layer.

@Mtt Good point. I hadn't thought of (for example) shared iPads.