I hope you've at least once stumbled upon the existence of https://noyaml.com/ and/or, at the time, were familiar with the quirks regarding number interpretation.
This and a similar suggestion in another thread may sound nice and easy, "just add a constant stream of noise", but it assumes you can generate enough constant noise and be able to intersperse the noise with valid commands without being able to distinguish these events. The problem is not necessarily that you want to hide (to a network adversary) that you've been typing. It's that you do not want to reveal, through some side-channel, what the exact contents were.
On the openssh-unix-dev mailing list, someone recently pointed out[0] that just periodically (without jitter) sending out packets may be problematic due to subtle differences in clock timing. Aside, they also link to a presentation[1] [PDF] that shows influence of temperature on clock skew (especially page 18) and that this gives a possibility for fingerprinting.
Then there's the challenge of keeping SSH interactive enough that people do not experience too much input lag while typing. What if the user typed a character, but due to such a timing side-channel preventive measure, that character needs to be sent in the next packet, adding latency to the user experience? Surely it improves security, but it may add too much frustration for regular usage.
But I don't think the conversation here is about anonymity, its about side channels to discover the actual content of the SSH session. The OP is looking at determining the command typed based on keystroke timing. The attacks you link would work for any traffic that could be intercepted, SSH or otherwise, and they wouldn't give any info about the content of the stream.
If we're just focused on removing all traces of keystroke timing from the channel, then I think a decoupled SSH transport layer which is providing say 1kB of zero-pad every 20ms to the the shell to fill up, along with a FIFO to spread that out, and maybe some logic to ramp up and down the channel bandwidth based on queue length, you would go a long way to mitigating this specific attack.
Another post (https://news.ycombinator.com/item?id=41148517) suggested "outline speedrunning" or "recursively outline". The gist: write outlines and recursively write outlines for those outlines until the items are small. I think that method complements the authors post.
One thing I'm doing since a few months is creating a fresh directory for every side project I start. Even if it's just "I wonder if I can (easily) extract all course information from this really slow school website that only offers a search bar" (it appeared to be easy). For a bit of structure, each directory starts with YYYYMM and a dash, and a few keywords that remind me what next side project I just started.
Inside the directory, there should be at least one text file containing steps I took, ideas I had, or URLs I visited, to provide my future self a nice amount of context whenever I'm revisiting that side project. For the course information side project, simply documenting the steps I took in the browser while visiting the school's website and just pasting the 'Copy as cURL' command for a certain request inside that file is sufficient! (I'm aware there's a lot of knowledge hidden in that previous sentence; it's more an example of writing down what steps you took while tackling the problem)
The directory listing, over time, should also give a nice insight of all the things I've discovered, tried, or perhaps even finished.
You might like Notion, Obsidian or similar note taking apps - using it as basically a stream-of-consciousness tool, recording what you've tested, those notes you mentioned, but also being able to embed code, screenshots, etc. _all in-line_ really helps with the context reacquisition. Just lookup the shortcut to insert the current datetime (Evernote was "ctrl+;", Notion I think the best is probably "@now") and you've got good timestamps as well.
I'm not super familiar with Obsidian, but from your general description I think it might work best - I _think_ you can just have your (markdown?) Obsidian file in the project folder like you mentioned.
I'm aware of various information management tools, but exploring these tools, getting familiar with specific syntax or intricacies of usage needs a higher activation energy than simply running $EDITOR and typing away.
I'm usually working on hardware that's at least a couple of years old, and the experience with modern day desktop applications (websites in an Electron-wrapper, if you will) is that they're terribly slow on relatively okay, albeit older, hardware. Not to mention (but I haven't checked!) that you'll need the application to search through your content, perhaps due to the use of some database, instead of grep(1)ing for keywords inside text files. I'm not opposed to optimized, application-specific search, but, for personal usage, if I need the application to search through content, this makes data portability much more difficult.
I will say (because you specifically pointed out you haven't checked - I do enjoy clear and honest communication online) that Obsidian at least deals with straight Markdown files, so while (per my current understanding) the program itself isn't OSS, the datafiles are all easily importable into other systems, and the files themselves are grep-able and mostly human readable (all text is there, but extra features and layout will not show up as nicely as in a Markdown-specific renderer) in any text editor.
After looking a while at the 1 degree rotated <div>s, even HN feels tilted. It's a nice effect, but I would only use it as an animation while hovering (i.e. animate from 0 degree to 1 degree rotation, if you must. Otherwise, don't do it to keep the interface clean). Personally, I would leave out all animations, unless they visually help the user with a certain task.
And since you're asking, here's a few things that come to mind regarding the design:
- Stick to one font family. There seems no need to semantically distinguish different parts of the text; the use of font size and decoration already take care of that. I would keep the Bricolage Grotesque and ditch the monospace font.
- It should be interesting to read the stories on the main page, but in the current setting, three columns (on 1920x1080) feels to crowded. Two columns seems to be okay for that screen size, but perhaps three columns work as well if the padding is a bit different (see next point).
- Try fiddling around with the left and right padding in the quotation blocks, as well as text justification. On smaller screens, there's about three to four words on each line, and lots of empty space.
- The ten "things to do" are identically styled as the call to action buttons ("Share your story" in the menu bar, "Start doing things that don't scale"), but there's no action involved. I think the quotation block style would be better: blue background, yellow title (e.g. "Ask for help and referrals"), white text (e.g. "Leverage your network for initial users and incentivize them to refer others to rapidly expand your user base."). The user can easily distinguish the important stuff (title) from the accompanying explanation, and it doesn't look clickable.
And some other nits:
- A few "Source" links are broken.
- Privacy Policy gives a 404.
- On the /startups page, I already forgot what the ten recommendations were. Perhaps add ten filters that automatically select the stories that involve the particular recommendation.
- Does the epicness scale go from 1 (low) to 10 (high) (or 5 it seems?)
Thanks for your great feedback! You gave me lots of good ideas to make the site better. I'll fix the turning boxes and work on the layout. I'll also make the text easier to read and fix the broken links. Your ideas about the "things to do" part and adding ways to sort stories are very helpful. Thank you for taking the time to help me improve!
It's likely the authors used an existing conference template to fit in their paper's contents. Upon sending it to the conference, the editors can easily fit the contents in their prescribed format, and the authors know how many characters they can fit in the page limit.
arXiv typically contains pre-prints of papers. These may not have been peer-reviewed, and the contents may not reflect the actual "published" paper that was accepted (and/or corrected after peer review) to a conference or journal.
arXiv applies a watermark to the submitted PDF such that different versions are distinguishable on download.
It's interesting to see how requesting your data[0] could take up to 30 days! I haven't yet clicked the button, but it would be interesting to see what's in the data dump.
> Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an empty supported client protocols buffer may cause a crash or memory contents to be sent to the peer.
I hope you've at least once stumbled upon the existence of https://noyaml.com/ and/or, at the time, were familiar with the quirks regarding number interpretation.
reply