Optimal Characters Per Line - <AUTHOR> http://mikeyanderson.com/optimal_characters_per_line <comment><USER2> This is about the font size I read most stuff on the web at, so I guess I agree. The font on most sites is too small for me, so I browser-zoom them in 1-3 stops.

As long as browser zoom works, though, I don't think it's a huge deal if people have preferences for larger or smaller fonts. Firefox, at least, even remembers your zoom level between visits to the same site. What really annoys me is that browser zoom breaks some sites. I'd recommend testing your site at one or two zoom levels in and out and see if the results are at least vaguely usable.

<comment><USER3> The problem I've got with browser zoom is that it behaves wildly inconsistently across sites. In some cases, it will expand all containers along with the font size, frequently pushing page elements off the viewscreen. It almost always scales images, which I generally don't want. In some cases, narrow-format pages end up with ridiculously skinny columns of text floating in a sea of either whitespace or distractions. And in far too many cases, pixel-perfect styling elements break completely, leading to wrapped navigation bars, buttons with clipped text, or just plain broken page layouts.

Sadly, Web 2.0 seems to be desperately trying to re-tread all of the worst aspects of 1.0 design with framesets, animated banners, moire backgrounds, and the like. Some of the worst comes from Google -- G+ and many of the newer Blogger styles are completely unreadable.

gwern, who posts frequently to HN, has one of the better site designs. Medium is actually Excellent. But it's rare enough that I encounter such sites that they're far more remarkable than they should be.

</comment></comment><comment><USER4> Very, very hard to read due to way too large font. I immediately had to zoom out in order to read it.

I don't think the author can show that this big font provides better readability.

One can easily make assumptions on how far the average reader views the screen and optimize the font size to that. As the comments here show, the font size selection here is too large.

<comment><USER5> Curious; what type of display were you reading on? How big is it? What was its resolution?

\</comment></comment><comment></comment><comment></comment><comment>--

Reading it on a 27" 2560x1440 display was really nice. Same in vertical mode on a 9.7" iPad, but not so good in horizontal mode; it felt constricted like watching a letter-boxed 16:9 movie on a 19" 4:3 TV screen.

What I've found is that optimal text formatting varies greatly across devices. This is very hard to design for due to the variety of screens. From small screen devices like cell phones and gray-scale Kindle's, through larger 24" \- 30" monitors and even larger HDTV's. On top of that there are DPI variances.

I've always been a fan of MVC, separating the model (actual document data/text/pictures) from the view (how it's displayed), and using a controller (device/screen-specific code) to display things optimally.

It would be nice if there was a standard that existed allowing authors to simply write documents, saving them as models. Then, each device could read from a standard model file and, using custom controller code, generate a view displaying the text/images optimized for its display.

Right now you see web developers creating multiple CSS layouts for different screen layouts. This works for most cases, but not edge scenarios. It feels very hacky, and I can't foresee people building websites/content-delivery- mechanisms like this 10 years into the future. There must be a better way.

<comment><USER6> > It would be nice if there was a standard that existed allowing authors to > simply write documents, saving them as models. Then, each device could read > from a standard model file and, using custom controller code, generate a > view displaying the text/images optimized for its display.

This standard is called "HTML". What you describe is the _entire idea_ of HTML. Frankly, it's embarrassing that a web browser presented with a long stream of text won't keep the line lengths capped at a reasonable length.

<comment><USER7> Yes, this is why it drives me crazy that Safari on iOS does not wrap text as you zoom in. Every browser since the beginning of time has been able to properly wrap the text as you increase the text size, and Apple has totally broken that.

<comment><USER8> That was one of my biggest complaints about iOS coming from Android. Reading Hacker News comments on iOS is a horrible experience of swiping back and forth, back and forth.

<comment><USER9> What's worse is that the other browsers decided to emulate this bad behavior. Most of the mobile browsers now no longer properly wrap text when zooming, where once they did.

</comment></comment></comment></comment></comment><comment><USER10> Large fonts stress my eyes more than smaller ones. I fit less words in the center of my vision with a large font, which means I read slower and my eyes have to travel longer.

Having ~60 character columns is the important thing. Large fonts, not so much.

<comment><AUTHOR> One of the difficulties of a screen is that you can't control how far away the reader is from the screen. With a book and mobile device the user can easily adjust distance to match their preference—on a screen you can make the type responsive to screen size, but if someone is closer to the screen or further away there isn't much that I know of that can help get this dialed.

<comment><USER11> There's always responsive typography using the webcam :) [https://hacks.mozilla.org/2013/02/responsive-web- typography-...](https://hacks.mozilla.org/2013/02/responsive-web-typography- with-webrtc/)

<comment><AUTHOR> With Xbox One having an always on camera facing you this might actually be possible, although I think that the right size probably depends on your eyes and vary depending on how far or near sighted you are—that's just a guess.

</comment></comment></comment></comment><comment><USER12> Ironically I found that page hard to read. I think it might the constantly having to switch my eyes back at the end of a line breaks the mental flow of the sentances. Anyone else experience similar?

<comment><USER13> I had the opposite experience, although I would have preferred it just a teeny bit smaller. Coming back to read long lines on HN is quite awkward.

There's a reason I limit my source lines to 78 columns too. Well, many reasons if you consider 80x25. :-)

<comment><USER14> FYI, you can get a plug-in such as Stylish for a lot of browsers that will let you override styles for specific sites. For lightly formatted discussion sites that I visit often, I typically set a font and a (max-)width for comments and related material that I find comfortable.

For HN, I personally set a max-width of 700px on .comment and pre blocks, to go with fonts of around 18px. If anyone new to Stylish wants the exact overrides I use to paste in verbatim, feel free to ask and I'll look them up.

</comment></comment></comment><comment><USER15> We can't really debate the issue given that some of us are seeing a huge font (much larger than the 'magazine held up to the screen'), and some a more reasonable one, all depending on the width of our browser window. Apparently it flips between the two sizes around 900px width.

I don't think that's what the author intended. Back to the drawing board I reckon...

<comment><USER16> It's switching to mobile formatting. The text is smaller, but the phone is also closer to your face. I thought it was cool how you could switch layouts on the fly like that.

</comment></comment><comment><USER17> I find it interesting that both the blog entry and the picture of the physical book he's using are not justified but simply jagged right.

I've written books in both LaTeX and QuarkXPress and they were always using justification.

Actually most books in english / french are justified (and probably many other languages) are justified. Heck, I couldn't find a single book here not using justification and my oldest book (16th century!) is using justification!

As a matter of personal preference I find justification way easier on the eyes than justification (as long as hyphenation is done right) and I'm very thankful that most books out there are using justification.

Of course justification on the Web is hard, especially without hyphenation and even more so if you try to use lines with few characters.

But I find it a bit weird to "make a point" by taking of picture of a book which is jagged right when something like, say, 99% of the books out there are using justification.

<comment><USER18> I think your qualification "as long as hyphenation is done right" is the key here. I don't know of a single web browser that lets the user turn hyphenation on and off, and while CSS3 supports hyphenation, browser support is inconsistent. (Chrome is the most notable problem child here, oddly enough.)

And you could go farther and say "as long as _justification_ is done right." All browsers that I've seen do justification use a very simple algorithm compared to LaTeX, Quark, and InDesign, and bad justification -- which tends to leave huge gaps of white space between words -- is harder to read than ragged right.

Personally, I think the best you can do _reliably_ on the web right now is ragged right with CSS3 hyphenation enabled for elements that contain body text. But I wouldn't turn on full justification.

<comment><USER19> It is really odd to me that Chrome is behind for hyphenation. It is such a crucial thing for typography.

</comment></comment></comment><comment><USER13> _I hope that this article has at least caused you to think about the way your web page displays text._

I find it sad that the web page (every web page) has to do it. It would be so nice if the web page were text, which the browser displayed.

</comment><comment><USER20> > ...on this blog their are about 75 characters...

Sorry to be that guy. I only point out grammar flubs if they are on 20px font or greater.

</comment><comment><USER3> I'm all about readable fonts, though mikeyanderson is going a bit overboard in the _too big_ direction.

He's also committing the fatal sin of mixing ems (for his h1 title font size) and px (for his h1 line height). The result is overlapping characters: [http://i.imgur.com/tEplJmv.png](http://i.imgur.com/tEplJmv.png)

I've griped on HN (and elsewhere) more than once about small fonts, low contrast ([http://www.contrastrebellion.com/](http://www.contrastrebellion.com/) can't get enough good words from me), and the reading-friendly tools such as Readability.com (despite some recent updates I'm not entirely happy with), InstaPaper, Pocket, etc. The latter are a great way to avoid this pain with minimal effort, and "read now" bookmarklets make this pretty near instant for most users. The styles presented by any of these services would do well as a default for virtually all content-rich sites.

I also have become all but obsessive in restyling sites whose CSS fails me. Which is to say, most of them (including Hacker News: [http://stylebot.me/styles/2945](http://stylebot.me/styles/2945)). Using the Stylebot Chrome plugin, I've created, as of this writing, 819 stylesheets (some applied to multiple sites, some the same basic "unstyled.css" sometimes lightly modified). I think I've reached the point where I can make some fairly definitive statements, at least as far as UI/UX goes:

⚫ Use ems. Do not use px (graphics positioning excepted). _NEVER_ mix ems and px.

⚫ Provide a high contrast between foreground and background. No, you're not limited to black on white (though it's a safe choice). Brad Frost's website illustrates a styled but very clear example (and it's what he does): [http://bradfrostweb.com/](http://bradfrostweb.com/) (It's also a beautifully fluid site).

⚫ While we're talking about contrast: take your "but black on white is too much contrast" talk and bin it. The guidance for brown type on an off-white page is for paper. Which is a reflective medium. Screens are, almost always, emissive. Which is to say, they have a maximum brightness, a _much_ lower native contrast ratio than paper, and their display properties get markedly worse as ambient light levels increase. Most displays have a brightness/contrast control which can _reduce_ the maximum brightness, and on many devices this is either automatic or easily accessed by the user (Fn+PgUp/PgDn on my Thinkpad, Macs have similar controls). However they cannot be pushed _over_ their maximums, and in many cases, that's going to be insufficient to read your tiny low-contrast font. In my experience, any text at #333 or lighter is already _too light_.

⚫ Single-column designs are almost always preferable to multi-column. With an adaptive width, this will frequently address the needs of both desktop and mobile users with very few additional adaptations.

⚫ Respect your user's font choices. There are two classes of user: those who've selected font sizes to address their reading comfort and/or visual needs, and those who have no idea or clue. By forcing a specification on them, you're frustrating both. Using relative sizes "medium", "smaller", "larger" is a better bet.

⚫ Break the zoom button and you may not die, but your page is dead to me.

⚫ Don't include iframes with their own stylesheets. These _cannot_ be overridden by the user. And yes, I'm talking to you, Amazon. Given the visual discomfort these elements present, I've simply set them to "display: none".

⚫ Don't explicitly scale HTML elements (p, a, li, tr, td, ol, ul, dt, dd, blockquote, pre). Style classes or IDs instead. One of my quick-and-dirty fixes is to apply an "important!" inherit property to each of these elments. CSS hackers will know about reset.css stylesheets, these can be useful to users as well.

⚫ Don't push your text to the edge of the screen. Another style I apply to virtually all sites is a "padding: 0 2em 2em 2em;" to the main text block. Generally padding at the top isn't necessary, but keeping the text from running straight into the gutter greatly improves readability.

⚫ It's hard to go wrong with a 45-55em max-width, auto width, and auto left and right margins.

⚫ Put some fucking padding and/or margins around images and other inline elements. 0.5 - 1em at a minimum.

⚫ CSS columns (a trick I picked up recently here on HN) are a good way for presenting your navigation / sidebar elements. Not supported in all browsers (what is), but the good ones do. You can see them used in the article below.

⚫ And if I sound fucking grumpy, it's because I _am_ fucking grumpy. My first response to opening your goddamned webpage shouldn't be "fuck it, do I really want to spend time fixing this?" Because usually the answer is "no."

I recently posted to reddit with several specific examples of sites converted from multi-column to single-column:

[http://www.reddit.com/r/webdev/comments/1tm4ox/user_site_res...](http://www.reddit.com/r/webdev/comments/1tm4ox/user_site_restyling_multicolumn_vs_fullwidth/)

<comment><USER21> I agree with 95% of what you said, the main exception is using em for styles. If you are designing for the screen, pixels are your medium and you should be aware of them. If you are using any graphics elements you will need to use px anyhow and then you are mixing - which I agree is bad. Ems can have unexpected consequences as well. For one, because it is a measure relative to the size of the capital M, sizes can change when the parent font-family changes (moving from a proportional to monospace font, for example.) Also, it is relative (like %) so if you wrote a CSS rule like this (you shouldn't, but it is to illustrate an point)

div {font-size: .5em; }

And you have this HTML

Hello

The actual size of "Hello" would be .25em. If you want a font to have a font- size of, say, 14px on screen, then set it as that and you'll have less worries about it changing unexpectedly if the font of its parent changes. I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing.

I know this is not orthodox, but I've been doing front-end dev for 12 years and I promise this practice has saved me from a lot of hassles.

<comment><USER3> To be clear: about 80% of what I know about CSS I've learned in the past 9 months or so, despite having dabbled in HTML since the late 1990s -- I've long hand-tooled my own HTML for my personal websites and many discussions which allowed HTML markup. And I'm coming at this almost completely from the user experience perspective. To be more specific, _my_ user experience. I respect your experience, but the practices I've seen in live code are ... simply infuriating.

 _If you are designing for the screen, pixels are your medium and you should be aware of them._

Pixels are _an aspect_ of your medium. Not all pixels are created equal: they're not the same size, brightness, or color. Screens have hugely varying numbers of pixels, and can be resized pretty much at whim. Used to be you could rely on having at least 80 columns of text visible, with handheld devices, that's rarely a safe bet (reading the comp.risks digest, with its fixed-format presentation became all but impossible). I'd argue that ems and percents should be your principle units.

Where I use px it's for image padding (though I'm switching to ems for that), and border widths (though again, ems might actually make more sense, I'm just used to specifying 1-8px borders ...).

My point is that, _for content_ , that is, text, your measurement should principally be _about text_. Your ems font sizing point has merits (well, except for your use of 14px for your font size), but you've got plenty of alternatives: smaller, medium, larger. Or absolute sizes: (though I'd suggest avoiding these): xx-small, x-small, small, medium, large, x-large, xxlarge. And realizing that '0.5em' is _really_ saying "scale this to about 50% of normal text with" pretty much obviates your complaint that the typical character isn't 1em in width. Or, if you want a fixed relationship, percentages. I usually set my header tags at 150, 140, 130, 120, 115, 110, though I may bump that up (200% or 300% for major heads) or down (5% or smaller steps). And I'll often set these differently for header, article, aside, and footer elements (larger, normal, smaller, and smaller, typically).

Example of using ems for height and spacing is the drop caps on both my subreddit and Dreamwidth styles.

My focus on single-column layouts _for text content_ (note that I actually _like_ the multi-column mode for navigation and promotional elements -- when in sufficiently wide-screen displays) means that pixel-perfect placement is rarely an issue. I've also taken to styling navigation lists as "display: inline" or "display: inline-block" elements, several instances on the examples screenshotted at reddit, specifying inline-block gives you access to the :first-letter pseudo-element which you can see in the reddit menus on my personal subreddit [http://www.reddit.com/r/dredmorbius](http://www.reddit.com/r/dredmorbius). The inline styling means that you don't really have to worry about the width of the internal options -- they space themselves out appropriately.

And my use of margins _plus_ padding means that you get both a fluid text box _and_ a minimum guaranteed margin. 2em is tight but workable. This also means that you can set your default font for containers, say:

           #container

Setting a font size for the body (I actually usually set this smaller than my preferred reading font: 12pt for body, 15pt for the article, and possibly others for the header, aside, and footer elements (rarely below 10pt). This lets me set the overall page bounding in the #container segment (margins and padding), without skewing the overall widths of the other page elements, _and_ preserving the option of individually scaling fonts and line heights within them. And if my padding widths are slightly off between header, article, aside, and footer, really, it's no big deal. The medium is _inherently_ variable.

As an example of where things go haywire with px-specific stylings, Google+ uses a really complex bit of HTML to render its post and comment scores. It includes independently placed "+", tens, ones, and rating button elements. And if you're not using precisely the font sizes Google assumes, the characters are horribly mis-aligned and clipped. I've had to fix this multiple times as G+ changed its classnames (some completely asinine CSS minifier/obfuscator they use). See here:

[https://plus.google.com/104092656004159577193/posts/b4azoTVU...](https://plus.google.com/104092656004159577193/posts/b4azoTVUom4)

 _I save em measurements for things that are inherently associated with their parent font such as line-height and letter-spacing._

Good practice there.

I swear to fucking god I'll shoot the next HTML monkey I lay my hands on who uses px for line heights, or fucks with letter spacing. It may just be with a squirt gun, but I'll shoot 'em.

The other factor to consider is that you also have access to the @media selectors which can key off of display size. I make use of this on my Dreamwidth blog, [http://dredmorbius.dreamwidth.org/](http://dredmorbius.dreamwidth.org/) The Kosmic Kat logo is a background image of the #header block which actually includes all of the top-of-page elements, not just the title segement. Given LiveJournal's HTML template, in order to accommodate both wide and narrow screen placements, I had to find a transition point at which the logo moves above the title text, and the right margin for the blog and post titles is removed. It's not a totally elegant solution, but it works sufficiently for me: I get my little branding element, and the text doesn't get horribly mangled.

</comment></comment></comment><comment><USER22> In my experience, it's difficult — if not impossible — to please all of the people all of the time. My startup (www.BeeLineReader.com) has browser plugins that reformat text and display it using eye-guiding color gradients. We get comments from people telling us that the plugin's text is too big, and we get comments telling us the that the text is too small. I suppose we should be happy that the ratio of these comments is roughly 1:1 — maybe this means we've struck the right balance?

Similarly, we get people telling us that we absolutely must use serif fonts, and others telling us that serifs make text harder to read and must be avoided.

Since our startup is focused on enhancing readability, we take these concerns and comments to heart, but we have realized that much of readability is more subjective and less guided by universal, hard-and-fast rules. So now we offer multiple text sizes and are going to incorporate multiple fonts.

...But then you get into the problem of offering too many choices instead of telling the user what is right (the paradox of choice). Sigh.

<comment><USER14> _Since our startup is focused on enhancing readability, we take these concerns and comments to heart, but we have realized that much of readability is more subjective and less guided by universal, hard-and-fast rules._

A big challenge with typography, and design more generally, is that sometimes what is objectively superior in some measurable sense (retention, reading speed, etc.) can contradict what a test subject prefers subjectively. I agree with your caution about providing too many options at the expense of simplicity, but when you're asking a question that doesn't have a single universally correct answer, I don't see that you have any better strategy available. Interesting idea for the reading aid, BTW.

<comment><USER22> Absolutely agree that users' subjective perceptions about readability don't always line up with actual results. We have a reading test on our website (controlled and randomized, n = 15,000), and the vast majority of test subjects find that it improves reading ease.

Interestingly, among the minority of subjects (15%) who perceive that our tech did not improve readability, most of them actually read faster in the test condition than in the control.

At the end of the day, both subjective and objective results matter. People don't willingly use a product that they don't like, and most people aren't interested in a product that is only playing games with their mind. So we have to build products and features that help people, and then provide education so that people feel can make fully informed decisions.

</comment></comment></comment><comment><USER23> I think the author has a point .. however we're all conditioned now to the standard-ish font size on the web. We all sit at a distance from the screen optimised for a particular size - and as most sites are about the same we zoom in or our a little. Changing that is just jarring.

The number of characters per line is, however, important. I tend to either resize my browser to narrow sites like HN or use the 'Instapaper Text' button to totally transform the page.

One things missing in this article is talk about line-height. The longer the line of text and the longer the paragraph, the more line-height you need. The white gap between the two lines helps the eye to find the next line as it quickly scans back to the start.

Many news sites still use a small line-height reminiscent of newspapers where whitespace is expensive. I think the designers think it gives the feel of 'real' news.

TL;DR: lines around 70 - 80 characters are good. But more important is sufficient line-height to scan back to the start of the next line instantly.

<comment><USER24> Thanks. A suggestion - the TL;DR is much more helpful if it is before the text - like an abstract.

<comment><USER25> It's a TL;WR (too long; won't read) if you put it at the top.

</comment></comment></comment><comment><USER26> For the record, I zoomed out on this website for a more comfortable read. Not really the way to drive your point home I think.

</comment><comment><USER27> Nice post. Something similar that was posted on here a while back is the "Interactive Guide to Blog Typography": [http://www.kaikkonendesign.fi/typography/](http://www.kaikkonendesign.fi/typography/)

</comment><comment><USER28> _On each full paragraph line of text on this blog there are about 75 characters—which is widely regarded as the most characters that you can put on a line and still have it optimal for readers._

I still use 80 columns as the limit on all the text documents I write, including source code. Occasionally I'll push it up to 128 but most of the time even I personally prefer 80 as an ideal width.

Also, who maximises a browser, unless their monitor is tiny? Especially with resolutions where they are today. I have around a dozen other apps open at the moment and none of them are maximised.

<comment><USER29> I maximize them. I'd rather use a tiling VM with a bunch of virtual workspaces than having to deal with resizing and minimizing windows.

<comment><USER3> It really depends on my workflow.

When I do have the luxury of working on only one thing and focusing on that, it's great. Much of my work (technical, research, or otherwise) involves flipping between different applications or windows. Usually a terminal (or several), and one or more Web pages open for reference.

<comment><USER29> Yes, so does mine, that's why I use multiple virtual workspaces, with one or two windows per workspace. I have 18 open windows at this moment, with 16 of them maximized.

<comment><USER3> 8 workspaces, 20 windows (a low count), none presently maximized (though 4 are near-full-screen).

</comment></comment></comment></comment></comment><comment><USER30> As others have pointed out here, the article above is much too large on an Apple 27" Cinema Display.

One of my peeves with web pages in general is I choose a default font face, size and weight based on my monitor or laptop screen and the distance from which I view. The first thing usability experts do is override that with a custom font face at fixed point sizes. I don't get bored looking at the apps on the desktop using my preferences, why is it different on the web?

</comment><comment><USER31> I like the linked site, personally. I've always liked big huge readable text and will zoom or text zoom a site to make it so.

That said, I do think it is tougher to scan his site for relevant headings/navigation/etc. that I want to interact with. The text is just so huge and there's nothing else and even just quick checking the headings you have to scroll a lot. Smaller text would allow more glance-ability.

</comment><comment><USER32> Maybe the author kept under the character limit that he proposed, but due to large font I still had trouble reading. Not only was it hard to find the next line after finishing the previous one, but it was also hard reading each word. I only want to glance at a word to know what it is - which is why those "the the" tricks work.

</comment><comment><USER33> So there were some great points in there, all of which were valid. But immediately addressing those points doesn't mean using large type follows.

Side note: as monitors increase in size, I'm curious of the general population is increasing the distance between their eyes and the screen

</comment><comment><USER34> I don't know. I found the article very hard to read.

</comment><comment><USER35> You can never really know how the end result is going to appear to your users/readers because everyone has different types of monitors, resolutions, layouts. For example, I have 4 monitors at work that have all been rotated 90 degrees from the "norm" \- in other words they're all in portrait mode. My browser window dimensions are thus longer than it is wide - which I think is not what most web developers expect. Furthermore, I really do enjoy small fonts and much prefer to see as much of a site on 1 page as possible. I had to zoom out of that page just to be able to read it comfortably without scrolling too much.

</comment><comment><USER36> did anyone else quickly notice how many eye movements they were making on this page and how irritating it was? i've never before noticed this to be a problem... its surprisingly distracting, and i felt like it was slowing me down which became frustrating quite quickly.

i don't think i have a particular bias about this - i usually use tiny fonts and want my screen filled with text for coding purposes - although i do tend to stick to 80 chars or less per line for code as well but i think that because code isn't read quickly i've just never noticed this before...

</comment><comment><USER37> When I'm reading a book, I've already decided that I'm going to read every word. On your website (on any website), I'm going to skim first to evaluate how much fluff and filler is written and to hopefully get to the point. With such large font, there is so little content in front of me that I'm actually frustrated with the encumbrance. If I didn't know better, I'd feel insulted that you deemed it necessary to try to control my browsing experience so strictly.

</comment><comment><USER38> Ironically when I read this on my iPhone the text size was much smaller than an average novel. (Also, the line-heights need some TLC).

I like larger text, but I find this too big (when I read it on a computer). And I think for valid reasons beyond just personal preference. For starters, it's hard to scan or keep track of where you are in the post. I don't think Nielsen would hold this up as a great example of scanability - on my 11" Air I get just about two paragraphs on screen at the same time.

</comment><comment><USER39> "I'm sick and tired of cramped websites that have tiny type and don't use the whole screen well"

It's own site doesn't use the whole screen. So pot...meet kettle.

</comment><comment><USER40> Seems silly to say it should mimic a book, without acknowledging that many different type sizes exist in books.

Though, in general I agree with the font size needing to be larger. I'm curious if it is as important as portrayed. Probably depends on the type of reading being done. And, as always, effective use of graphics trumps most "text size" decisions, I would think. (As I look over a comic with ridiculously small type.)

</comment><comment><USER41> Has OP A/B tested his claims and theories in any way, or is it just a tissue of personal preferences backed by rationalizations and just-so stories?

<comment><USER42> A/B testing is not the correct way to test what is objectively better. As we can read from here, people often have personal preferences to what they are used to and think are best. Unfortunately what people think is best is not necessarily same as what is objectively best for them.

If you put people into usability lab and test their reading speed and reading understanding with different text sizes etc. you get more objective results (that mostly agree with the OP as far as I can remember).

<comment><USER41> > A/B testing is not the correct way to test what is objectively better.

It's much less wrong than preference-based theorizing. If you switch to longer lines and viewer time on page increases...

> If you put people into usability lab and test their reading speed and > reading understanding with different text sizes etc. you get more objective > results (that mostly agree with the OP as far as I can remember).

In very different contexts than blogs or web pages, I'd guess, if your memory is not misleading you.

<comment><USER42> Here is good overview of the research:

How physical text layout affects reading from screen.

[http://images3.wikia.nocookie.net/__cb20060729105544/psychol...](http://images3.wikia.nocookie.net/__cb20060729105544/psychology/images/e/eb/Dyson,_M_C_%282004%29.pdf)

</comment></comment></comment></comment><comment><USER43> I actually found this really hard to read because of how large the text is, the author needs to reevaluate his font size.

</comment><comment><USER44> Limiting the text

Just a few letters per line

A novel concept

<comment><USER45> It's hardly novel.

<comment><USER46> FTFY: It's hard for a novel.

</comment></comment></comment><comment> tech-no-logical first thing I did to make it readable was hitting "ctrl -" three times. so the site kind of defeats itself in that respect.

I agree that there's an optimal number of characters per line, but it doesn't necessarily mean you need huge fonts. just make your content more narrow, or use a multi-column layout.

</comment><comment><USER47> I wholeheartedly agree with your point, but why do you use Facebook comments, displayed in a whooping 11px ?

<comment><AUTHOR> I wish that I could change do Disqus without losing all of my old comments. I had originally decided on Facebook I believe before this design of the site and now I'm stuck with it—if any one has a hack to change the type I'd love some advice. I can't seem to override the FB CSS.

</comment></comment><comment><USER48> I can't read this while doing something else - I have to select the window and scroll every few words.

<comment><AUTHOR> That's part of the point. If you don't get readers interacting quickly it's very hard to keep them reading.

<comment><USER4> Sorry what? Are you more interested in "keeping them reading" or actually making accessible web sites that are easy to read? What exactly does interaction have to do with it? When I'm reading a book, I really don't want to turn pages constantly.

</comment></comment></comment><comment><USER49> Shorter lines are easier to read. Long lines with large characters like in the OP's post are harder.

</comment><comment><USER50> For better readability, try 75 characters per sentence.

The larger font amplified the "wall of text" feeling.

</comment><comment><USER51> Oliver Reichenstein from iA did this much better in 2006. He also had a photo of a book next to a screen....

The 100% Easy-2-Read Standard [http://ia.net/blog/100e2r/](http://ia.net/blog/100e2r/)

</comment><comment><USER52> If anyone is confused like I was when I opened this, there's a media query that reduces the font size when your window is less than 900px wide. Full screen it and the article will have huge text.

</comment><comment><USER53> Maybe this is why, even on an 11 inch netbook, I generally surf the web with the browser window at about 3/5ths the overall screen width. I don't like columns that get too wide.

</comment><comment><USER54> I love how this carefully designed site is sensible with its readibility and then you get the Facebook-powered comments with letters smaller than ants.

Not OP's fault, but just a heads up.

</comment><comment><USER55> Information Architects has a much more thorough article on this matter:

[http://ia.net/blog/100e2r/](http://ia.net/blog/100e2r/)

</comment><comment><USER56> Nice, but here's an improvement: lose the 2-line section titles.

Make them slightly smaller so they fit in one line, and can be read in one fell swoop.

<comment><USER57> That is the one thing that jumped out at me. Otherwise I agree with everything.

</comment></comment><comment> ianet-goog I'm reminded of the 'Osprey - The Magic of Reading' paper by the late (great) Bill Hill

</comment><comment><USER58> Point #4 is basic journalism. Headline, nut graf + inverted pyramid.

</comment><comment><USER59> I hate reading on any screen but my black and white kindle.

</comment><comment><USER60> I nearly lost it at "inforamavores"

</comment><comment><USER61> Nm</comment>


Kaleidoscopic Iterated Function System - <AUTHOR> https://www.shadertoy.com/view/tdcGDj <comment><AUTHOR> A mind blowing trick to draw fractals using space folding

The video tutorial [https://www.youtube.com/watch?v=il_Qg9AqQkE](https://www.youtube.com/watch?v=il_Qg9AqQkE)

An older explication by another author : [http://roy.red/folding-the-koch- snowflake-.html](http://roy.red/folding-the-koch-snowflake-.html)</comment>


The node.js ecosystem - <AUTHOR> http://wiki.github.com/ry/node/modules <comment><USER2> I took a look at node.js for my latest project because it could seriously benefit from the asynchronous nature. I found that the ecosystem was too fractured for me to be able to quickly determine what would work best. What's the best node stack for someone coming from the rails world to use?

Sometimes no options is better than many options.

<comment><USER3> I recommend Express.js ( <http://www.expressjs.com> ). It's Sinatra-like and gives you static pages, sessions, and HAML/SASS templating. I've been using it with the project node-mongodb-native leveraging MongoDB as a datastore (although the Mongoose project looks like it might be a cleaner interface: <http://www.learnboost.com/mongoose/> ).

<comment><USER4> Express looks to still be a synchronous-oriented framework (which could just be the result of the documentation, but I did not see anything in the documentation that suggested helping write asynchronous Servers)

</comment></comment></comment><comment><USER4> The irc chan on freenode is frequently populated with helpful people. The community is still small enough where everything is on the main mailing list.

</comment><comment><USER5> From this it looks like there is only "the beginnings" of PostgreSQL support. Is this accurate?</comment>


Why Cassandra Doesn't Need Vector Clocks - <AUTHOR> http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks <comment><USER2> Since they're not likely to approve my comment on their blog, here's what I said:

"Way to misrepresent[1] vector clock usage in Riak! LWW deliberately ignores the vector clock. No one would use that in production without a strong assurance that they will never have concurrent writes. Also note that later in the post[2] Kyle shows how using them properly leads to zero data-loss.

[1] [https://yourlogicalfallacyis.com/strawman](https://yourlogicalfallacyis.com/strawman) [2] [http://aphyr.com/posts/285-call-me-maybe- riak"](http://aphyr.com/posts/285-call-me-maybe-riak")

To add on,

> Cassandra addresses the problem that vector clocks were designed to solve by > breaking up documents/objects/rows into units of data that can be updated > and merged independently. This allows Cassandra to offer improved > performance and simpler application design.

This is not solving the problem vector clocks solve, it is punting on the resolution issue. Perhaps LWW partial updates result in greater performance, but they only solve performance.

Listen to or watch [http://thinkdistributed.io/blog/2012/08/28/causality.html](http://thinkdistributed.io/blog/2012/08/28/causality.html)

To be fair, both designs are valid choices, but jbellis should be honest about his tradeoffs and not simply cast aspersions on other valid designs because they aren't the one that C* chose.

<comment><USER3> I concur; this is punting on the resolution problem.

As far as I can determine in testing with Jepsen, there are no cases where one can safely (e.g. in a way which guarantees some causal connection of your write to a future state of the system) update a cell in Cassandra without a strong timestamp coordinator: either an external system like Zookeeper, or Cassandra 2.0 paxos transactions.

Most of the production users and datastax employees I've spoken with recommend structuring your data as a write-once immutable log of operations, and to merge conflicts on read. This is _exactly_ the same problem that Riak siblings have--except that you don't get the benefit of automatic pruning of old versions, because there's no causality tracking. GC is up to the user.

<comment><USER4> > As far as I can determine in testing with Jepsen, there are no cases where > one can safely (e.g. in a way which guarantees some causal connection of > your write to a future state of the system) update a cell in Cassandra > without a strong timestamp coordinator: either an external system like > Zookeeper, or Cassandra 2.0 paxos transactions.

It depends on what you mean by "guarantees". In most real world systems, if you can actually have two concurrent writes to the same record, it is non- deterministic which write wins... which is precisely what happens in Cassandra if you have multiple concurrent writes to a cell without a strong timestamp coordinator.

There is a somewhat more complex case about scenarios where you have multiple cells tied to the same record being updated together, but even then it will look identical to if you allowed both writes to happen, but it was non- deterministic which one happened first.

While you can _create_ an timestamp authority that arbitrates precisely what happens when, the reality is that if there wasn't an already observable mechanism for determining this, who is to say which one happened first?

Really, the only problem you run into is if there is atomic validation logic you need tied in to whether the updates happen at all, which is what Cassandra 2.0's lightweight transactions really address. Without them, you generally _do_ need some kind of external authority or a "log concurrently and then resolve serially later" strategy. That sounds like a pain, but the latter in particular is again closer to how most of the real world operates (in particular, the world of financial transactions).

<comment><USER3> The world of consistency is rich: not all systems require serializability, linearizability, or any one write winning. It might be interesting to skim [http://pmg.csail.mit.edu/papers/adya- phd.pdf](http://pmg.csail.mit.edu/papers/adya-phd.pdf), [http://ftp.research.microsoft.com/pub/tr/tr-95-51.pdf](http://ftp.research.microsoft.com/pub/tr/tr-95-51.pdf), and pagesperso-systeme.lip6.fr/Marc.Shapiro/papers/RR-6956.pdf for a taste.

<comment><USER5> (asking for my self and other readers of this thread)

is LWW = Last Write Wins?

<comment><USER6> Yes.

</comment></comment></comment></comment></comment></comment><comment><USER7> Cassandra counters once were implemented as a blazing-fast vector-clock patch [1,2] that did not involve read-before-write on update. The biggest (IMO) downside is that it did not support decrements. So Cassandra tech leadership decided [2] to implement counters as "read, increment, write." However, that came with two major downsides: 1) counter updates were now no longer replayable--so if you experience an update timeout on the Cassandra side under heavy load or due to a lengthy compaction or some network fluke, you just can't replay it. You need to hope that it has made it over. Counters run on hope. But you can decrement them now. 2) read-before-write can severely limit performance in the case of a large number of counter writes (as the workload becomes much more read-intensive, unlike regular blazing-fast Cassandra writes).

1 - [https://issues.apache.org/jira/browse/CASSANDRA-580](https://issues.apache.org/jira/browse/CASSANDRA-580) 2 - [https://issues.apache.org/jira/browse/CASSANDRA-1072](https://issues.apache.org/jira/browse/CASSANDRA-1072)

However, in many many a use case for counters, you just don't need to decrement. And if you need to decrement, you can often get away with two counters, that you subtract from each other. So that's a shame, as restricting the use case for counters to be monotonically increasing would've been just the right trade-off for many users.

<comment><USER8> I think you've misread the 580 patch. By definition, you need to read the existing vector clock value before you can issue an update against it.

/Member of the presumedly incompetent Cassandra tech leadership

<comment><USER7> Based on the algorithm described in the link here: [http://www.slideshare.net/kakugawa/distributed-counters- in-c...](http://www.slideshare.net/kakugawa/distributed-counters-in-cassandra- cassandra-summit-2010) \-- the insert path does not perform any reads, unless the column is already in the memtable (so no disk read). Am I missing something?

<comment><USER8> That is describing the 1072 approach aka the one in Cassandra today. Incrementing without read-before-write was one of the reasons Twitter liked it.

Unfortunately, while you can increment _on a single node_ without read-before- write, you need to merge it with the existing value before you can replicate to the others. Read-before-replicate, if you will.

Theres a more recent, quite long discussion over [https://issues.apache.org/jira/browse/CASSANDRA-4775](https://issues.apache.org/jira/browse/CASSANDRA-4775) that boils down to, "this is actually the best we can do."

</comment></comment></comment></comment><comment><USER9> That's great, but what if you want vector clocks in Cassandra? For example, storing opaque blobs encrypted by a remote client. You might want to store both versions. Does Cassandra offer the ability to store lists of primitive data types and atomically insert/remove elements? This would allow clients to atomically append and then (with less need for guaranteed ordering) asynchronously attempt to remove the ancestor record. Even if the removal fails, future gets would pull the list and again attempt to synchronize to a single record.

I'd suppose that under very high contention you could have some problems, but at least you'd be able to implement vector clocks as a library without touching the Cassandra core.

Apologies if my question is common knowledge. And for anyone who is well versed in other key value stores, does it support vector clocks or something like the above (list elements with atomic append/prepend?)

<comment><USER8> If you want to manage opaque blobs then you should probably use Riak or Voldemort. Cassandra gives you a set of one-size-fits-most tools that by and large work very well together, but if you want more of a build-your-own- database toolkit, it is a bad fit.

</comment></comment><comment><USER10> I don't see what's so scary about vector clocks. I have no trouble with them in Riak. Sure, there's a little extra logic to deal with certain types of siblings, but honestly I haven't encountered any difficult edge cases.

But then again, maybe it's highly dependent on what you use Riak for. Anyone out there have any type of application they've built with Riak that did encounter issues with using vector clocks?

</comment><comment><USER11> It's worth noting that HBase has the same method of using LWW on column level updates. While this usually is what you want and like Cassandra it gives you the ability to do fast blind writes there are sometimes that you need to make sure you aren't having conflicting writes.

The solution that HBase employs is to have checkAndPut functionality. Basically what this lets you do is write a value and only successfully save the update if a given column is the value you expect.

So for example you could have a "records" table that has a column called "check" whenever you update a record you pull the old one, do whatever processing you want to do on it, set the "check" column to a new UUID and then save it with a checkAndPut where you specify the "check" column in hbase has to be the old check value you read. If any other process wrote to this row then it would have updated the check value with a new UUID and so this checkAndPut will fail thereby detecting the conflict. Now you can repull the row and handle any conflict resolution without blindly overwriting the changes.

<comment><USER8> Cassandra exposes functionality similar to checkAndPut as Lightweight Transactions: www.datastax.com/dev/blog/lightweight-transactions-in- cassandra-2-0

<comment><USER11> Ah, good to know that functionality was added. I haven't used Cassandra since the 0.6.x days so my knowledge of what's possible there is rusty.

</comment></comment></comment><comment><USER12> This isn't anything dramatically new. Essentially, there is a tension between data normalization and requirements for strong consistency.

If my data is more segmented, I can afford to be less stringent about it. I think that foregoing vector clocks in an distributed database entirely though, is a recipe for disaster, no matter how denormalized my data is.

</comment><comment><USER13> Riak/C* noob here. Couldn't I just store data as column cells in Riak?

        bucket: 'users'
        'jbellis/email', 'email@example.com'
        'jbellis/phone', '555-5555'

What would I lose by doing this?

<comment><USER14> Performance, mostly. To read both the email and the phone you'll have to make two requests (or a single multiget). The keys have a good chance of belonging to different replicas, too, and even if they don't, you are still going to have 2x disk reads.

<comment><USER8> You're also giving up atomicity on writes when you actually do want to update multiple fields at once.

</comment></comment></comment><comment><USER15> Avinash Lakshman make a decision early in Cassandra's life cycle not to use vector clocks for performance reasons. You gain performance, you lose the ability to safely update an existing key concurrently.

This is a reasonable tradeoff.

Cassandra has since evolved around this limitation: use write-once or immutable data, transform updates into appending new columns rather than modifications, handle all of this automagically through CQL datatypes, etc.

Really cool stuff. A nice way to evolve a product around a limitation and still be immensely useful.

But, seriously, it's a tradeoff. Defending that choice against those who question Cassandra is fine. But, jbellis has a history of claiming Cassandra is a "one-size-fits-most tool", proclaiming that vector clocks aren't needed in 99% of cases, etc. That's opinion presented as fact. Without omniscience no one really knows what all users/the market actually needs, what 100% of all use cases look like, etc. Let's cut the rhetoric and realize engineering is about tradeoffs.

I still wonder if Cassandra won't someday add vector clocks, just like they eventually added vnodes.

In Riak land, we have vector clocks. Do we pay a performance hit? Yes. Must we? Maybe.

In theory, vector clocks should only be expensive when updating existing data. If you are writing data once (the standard Cassandra approach), vector clocks should be free. They're not currently, but that's an implementation detail that Riak can fix. And we're considering fixing in the near future.

What about when you have multiple updates to the same key? You must pay a penalty there, right? Maybe. We're actively looking at approaches to reduce that penalty in the future as well. Summary: have multiple versions of an object, just append new version on write, read all versions on read and rollup siblings/LWW resolve. Basically, identical to "just append a column" that Cassandra uses.

It's easy to extend Riak to support the same operations Cassandra does, with the same performance characteristics, while still supporting conflict- detection for concurrent modifications. Best of both worlds. We'll like do it at some point too, as that's what engineers do -- we make products better over time.

As an side, a benefit of per-key conflict detection and siblings is that it doesn't require a sorted backend. The multi-version approach Cassandra uses requires sorted data to be efficient on reads.

While most users of Riak use the LevelDB backend today which is a sorted backend similar to Cassandra's backend (both log-structured SST systems), Riak also supports the non-sorted Bitcask backend for folks that want a high performance purely K/V store. Bitcask is about 10x faster than LevelDB in many workloads, because it doesn't waste time sorting/rewriting data. Write amplification really hurts for certain workloads.

Yet another tradeoff. Engineering is always about those pesky tradeoffs.

</comment><comment><USER16> I don't know much about CAP but it doesn't sound right to me.

Let's see, you store your data tuple for example for a position say {X,Y} as 2 coordinates. X in one column and Y in another one.

Now when it gets updated concurrently and it needs to merge two conflicting {X1,Y1} and {X2,Y2} positions you could end up instead with {X1,Y2} non- existing/impossible/broken position.

Is that really that easily broken? Or am I not thinking about it straight.

<comment> brown9-2 In Cassandra the second update agreed upon by the cluster would "win", so either (X1,Y1) or (X2,Y2). Since there is no clock mechanism there is no way for the cluster to see that the data has changed since the requester decided it wanted to update the value.

<comment><USER3> Rows are not isolated. You might see (X1, Y1), (X1, Y2), (X2, Y1), or (X2, Y2) if timestamps happen to conflict. [https://gist.github.com/aphyr/6402464](https://gist.github.com/aphyr/6402464)

<comment> brown9-2 Oh wow, that is bad. I was assuming that guarantee of row isolation was valid.</comment></comment></comment></comment>


China Helped Put "Dr" Tedros in Charge of the WHO – Is It Paying Off? - <AUTHOR> https://nationalinterest.org/blog/buzz/china-helped-put-man-charge-world-health-organization%E2%80%94-it-paying-136002 <comment><USER2> Why does it put "Dr." in quotes? The guy has a PhD in community health (and an MSc in immunology and infectious diseases). Why does it also neglect to mention that he had the support of George W. Bush for the position?

Oh, it's The National Interest, chaired by the widely "trusted" Henry Kissinger. To criticize Tedros's handling, they quote a political science professor and a human rights critic. That's "quality" journalism.

<comment><USER3> Not only does he have a Ph.D., but it's in Community Health (essentially, the social aspect of public health), which is the field most directly applicable to the WHO mission.

It's probably because he's not an M.D., but then what WHO does has a relation to medicine similar to the relation of climate to weather.

<comment><AUTHOR> Because he is not a medical doctor. If someone was presenting on the black holes and they had "Dr." in their title, there would be confusion albeit minimal on if the "Dr." referred to medicine or just a Ph.D.

"Dr." Tedros works in the health and medical field. A "Dr". in the title if plain misleading if he is not a MD or equivalent in other countries.

Many things were founded by Kissinger and other characters whom society might retroactively deem unsavory. Do you disown all of them or is this just smear by association. Various figures like Hillary Clinton, Obama have consulted with him. Do you now consider them tained too?

<comment><USER3> > "Dr." Tedros works in the health and medical field.

No, Dr. Tedros works in the public health (not medical) field and his doctorate is in the subfield of public health most relevant to his particular job. His doctorate in the field is far _more_ relevant than an M.D. would be.

> Many things were founded by Kissinger and other characters whom society > might retroactively deem unsavory.

You should probably ask that in a post responding to someone raising Kissinger as relevant, not a random downthread post from that claim, but I, for one, certainly view anything connected to Kissinger with suspicion, not automatically _wrong_ , but suspicious.

> Various figures like Hillary Clinton, Obama have consulted with him. Do you > now consider them tained too?

Both because of and independently of the fact of their association with Kissinger, and not "now" as if it was news, yes, I consider Obama and, especially, Clinton tainted.</comment></comment></comment></comment>


PwdHash (2009) - <AUTHOR> https://crypto.stanford.edu/PwdHash/ <comment><USER2> This was one of the first "deterministic password managers", which has become a whole species of side-project password managers. The major practical win for deterministic password managers is that they're ostensibly stateless; you only need to synchronize some very basic configuration information to make them work consistently. In practice, not so much: passwords need to be changed, or revoked, or customized. You should just use "pass" (or 1Password if you want something professional).

An interesting thing about PwdHash is that they observed how you can use site- specific authentication behavior to break phishing, something that U2F/Webauthn tokens also accomplish.

<comment><USER3> One non-obvious thing I really like about WebAuthn compared to PwdHash here is what happens when bad guys trick you into trying to give them credentials. I've now implemented all this manually so that gives me more experience of the unhappy paths which obviously are hard to test on somebody else's site (if you don't want to risk getting banned).

Imagine you're signing into [https://fake-google.example/](https://fake- google.example/) having been tricked into believing it is Google but with various different types of credentials:

* With a memorised password or similar strategy, you give them your actual Google credentials. Game over, you lose.

* With password managers you _might_ realise there is something wrong because it doesn't auto-complete. But you might (for various reasons) give them your Google credentials, after all you've been tricked into believing this is Google. Game over, you lose.

* With PwdHash you give them PwdHash(Google Credentials). Reversing that to find your Google Credentials depends on your entropy choices. For good passwords you win, but most user passwords mean you lose if the bad guys put work in.

* With most "Second Factor" designs including SMS, TOTP, and many dongle designs you give them the second factor and again, you lose if the bad guys planned for this.

* But with WebAuthn its "cookies" (which bad guys can get from the real Google by presenting your username) are themselves site specific. Your FIDO authenticator needs a cookie, and it will implicitly need the cookie to match the rpId, your browser insists the rpId must match the origin FQDN of the web site (fake-google.example in this case) but that won't match google.com so the authentication cannot succeed. You cannot give the bad guys your Google credentials even if you really want to, maybe short of sending them the actual authenticator itself.

[ Do not UPS your Security Keys to bad guys. I think even my deceased grandmother could have figured that out, if I read stories about people being successfully tricked into doing this I may despair about our species entirely ]

<comment><USER4> > _if I read stories about people being successfully tricked into doing this I > may despair about our species entirely_

You can't think in terms of "does happen" and "doesn't happen," you have to think in terms of "90% chance," "10% chance," "1% chance..." and so on. So many times I have seen people reject good measures by giving an argument to the effect of "Your system has a 1% chance of failure, which in my brain is stored as 'can fail,' so it's not an improvement over the old system that fails 30% of the time, which is also stored in my brain as 'can fail.'"

</comment></comment></comment><comment><USER5> This should just be how websites work. I see no reason that a site should ever transmit the user's password over the wire.

When you create a password send the client a salt, hash their real password client side, and send the hash over the wire. Treat it as you would their actual password and salt/hash it again.

Then when the user wants to auth send the client the salt you have on file for them^ and repeat. Bam. A domain specific password for every site even for someone who who reuses passwords.

^ inb4 "this creates another 'step' when logging in." Users will type their username and pw before they get the salt and the client will handle the rest.

<comment><USER6> What do you gain with the extra hashing on the client side?

The attack you're protecting against is a compromise of the server's password database. If the attacker has that, then they have the client side salt too.

<comment><USER7> Hashing on the client side prevents the server side from logging the plaintext password anywhere, and from intermediaries from seeing the plaintext password. Replay of the hashed value is still possible, without other measures.

Hashing a second time on the server protects from a database leak being used to access the site.

<comment><USER6> > Hashing on the client side prevents the server side from logging the > plaintext password anywhere, and from intermediaries from seeing the > plaintext password.

No it doesn't, because all of those attackers have access to the client side salt which is sent to the client in the clear.

<comment><USER7> They would have the client side salt and the hashed password.

Now, depending on the hashing algorithm, maybe it's easy to turn that back into the plaintext, but with a competent hash, it's not expected to be easy.

Edit to add, if the site does it in javascript, of course they (or intermediaries) could decide not to do it, or to also pass the plaintext with the hashed version. That's a separate issue.

<comment><USER6> If you have the salt and the hashing algo, it's trivial to build a dictionary. If the password is good enough to not be broken by a dictionary attack, it was good enough without all the extra hashing.

<comment><USER8> Having to mount a dictionary attack which may fail/ take an indeterminate period time seems like a win. Albeit only for users who reuse the same, strong password.

<comment><USER6> Exactly. And if they're using a strong password already than you haven't gained anything.

The dictionary attack on the client created hash and the attack on the server hash of the plaintext take the same effort.

<comment><USER8> An eavesdropper who overhears a password just has the password, but an eavesdropper who overhears a hash and a salt now has to run a dictionary attack which might only have a 99% chance of recovering the password.

In the first case, there's a 100% chance of the password being compromised, but in the second an attacker has to spend resources on cracking a password, and there's still a small chance that they're unable to crack it. The second case seems like a clear winner (I could still be missing something).

<comment><USER6> You're technically correct, but if they have access to the plaintext conversation, they can just steal the cookie that comes back.

So sure, you may have prevented the release of a reused password, but you haven't prevented anyone from impersonating your user on your site.

Depending on how they have access to your plaintext conversation, they could get your reused password from another site.

In other words, while this might make a slight difference in the stealing of reused passwords, it's not really worth the effort. There are far better solutions, like encouraging the use of a password manager.

<comment><USER5> > but you haven't prevented anyone from impersonating your user on your site.

That is the whole point. In this system the hash generated on the client is literally your password. It's just to provide some extra protection for people who reuse passwords that are compromised on the server or over the wire.

>There are far better solutions, like encouraging the use of a password manager.

That might be better but your solution requires telling billions of people to not reuse passwords and use a password manager. Or you could implement this on your site and your users are instantly better off. Real users are better off if we just make their behavior safer.

<comment><USER6> But it only helps real users in the rare case that someone has already compromised the secure connection between their computer and your server.

That's not a realistic use case if you use https on your site.

The effort in implementing this, testing it, testing fallbacks when Javascript is unavailable, testing every change with the fallback on and off, and so on, just isn't worth it for that absolutely tiny gain.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Used this extensively before password managers were abundant—even wrote my own bookmarklet for it ~10 years ago[0]. One thing to be mindful of: login URLs can and do change. When this happens, unless you can recall the hostname, you're completely out of luck.

[0]: [https://gist.github.com/jasisk/fc0283e84814c696d3cd](https://gist.github.com/jasisk/fc0283e84814c696d3cd)

</comment><comment><USER10> What a coincidence as I'm reading up on deterministic password generators:

\- DPG: [https://plevyak.com/dpg.html](https://plevyak.com/dpg.html)

\- MasterPassword: [https://masterpassword.app/](https://masterpassword.app/)

\- LessPass: [https://lesspass.com/](https://lesspass.com/)

I like the idea of such mechanism for my passwords, but I feel like having to enter a masterpassword so often actually poses as a vunerability. The password managers I currently use, normally enables me to use fingerprint or leaves some minutes before timing out so that I don't need to enter my master password as often.

One idea I'm having is to combine the deterministic and stateless aspect of a simple js generator, with a simple db that user can maintain with a online spreadsheet:

1.this db would store states for the calculator that user would need to manually re-enter, and it's URL would be only known to user (say a Google sheets, json URL)

2\. This URL would be stored for limited time on browser cache improving UX for short period of time.

3\. The db itself won't store secrets, just "metadata"

<comment><USER11> I've been using PasswordMaker for years for this and been quite happy with it.

[https://passwordmaker.org/passwordmaker.html](https://passwordmaker.org/passwordmaker.html)

On Chrome the extension you want is PasswordMaker Pro (not paid, it's just a name). It allows you to save profiles for different domains and saves them wherever it is Chrome extensions save data.

</comment></comment><comment><USER12> SuperGenPass[1] is a refinement of this idea. The code itself has been dormant for years[2], but the bookmarklet and mobile web versions still work great. In fact, adding the mobile web page to my iPhone home screen with Safari makes this a pretty straightforward way to make passwords accessible on mobile without worrying about syncing.

1: [https://chriszarate.github.io/supergenpass/](https://chriszarate.github.io/supergenpass/) 2: Since 2016 :( [https://github.com/chriszarate/supergenpass/commits/master](https://github.com/chriszarate/supergenpass/commits/master)

</comment><comment><USER13> This is definitely pre-2009, I built this at Stanford w/ the others and I was only at Stanford until around 2005. (But they may have continued updating it given the Firefox version number referenced.)

<comment><USER14> Hey man, totally unrelated but: kudos for your work on Mozilla Firebird (now Firefox). I can't believe you were like 16 or 17 at the time.

</comment></comment><comment><USER15> I haven't yet decided how I feel about this vs a full password manager (with unique passwords per site), but do kind of like the idea there's no account/vault: literally the entire usage is via a single password.

I have a suggestion to greatly increase usability:

Right now, as the owner points out, this relies on using a password starting with @@ to trigger this mechanism (which is a usability issue), and relying on the user entering their passwords into the web page (which is a phishing danger).

Given this already requires a browser extension, move the password to a UI within the extension, and instruct the user not to ever enter their password anywhere else (on why page directly). Use a button in the browser extension to trigger filling in the site-specific password. This avoids phishing the main password, avoids the @@-prefix requirement, and the extension could now also cache the password for some amount of time so the user doesn't need to re- enter it.

Interesting idea/project nonetheless.

Edit: oops, just noticed this is from 2009. I noticed lack of Chrome but not the ancient browser versions! Did this go anywhere?

<comment><USER16> similar ideas have been around for ages. for the most part they are unpopular because they have a number of severe usability issues: SSO sometimes uses multiple domains, password rotation requires either changing all passwords or memorizing a per-site generation, multiple entries per site requires memorizing a per-site key...

</comment></comment><comment><USER17> This reminds me of PasswordMaker[1], a neat tool that you can easily self host (or run offline from your filesystem) and customize. The basic idea is that you don't have to store any passwords, but you can still easily have a different one for every account. You generate a hash based on the domain/hostname and the master password.

It worked really well for a long time, tho eventually I ran into enough corner cases that I had to switch to a traditional password manager anyway. I still use it for some stuff however.

[1]: [https://passwordmaker.org/passwordmaker.html](https://passwordmaker.org/passwordmaker.html)

</comment><comment><USER18> This is equivalent to hashing passwords using a global public salt (the domain name). If it became popular enough, you could mount a trivial offline dictionary attack on popular passwords.

</comment><comment><USER19> This creates longer password even with a short master pass: [https://ss64.com/pass/](https://ss64.com/pass/)

</comment><comment><USER20> [https://en.wikipedia.org/wiki/Salt_(cryptography)](https://en.wikipedia.org/wiki/Salt_\(cryptography\)) (1970)

</comment><comment><USER21> This would break if the site owner changed their domain name, or more likely, they have multiple domains that redirect to the same IP address. Is that a serious flaw?

<comment><USER3> It's a problem certainly.

To be fair that would also be a problem for many automated or semi-automated password managers. I have PassFF for example and it's currently suggesting the password it knows for news.ycombinator.com, I think it would guess that hacker-news.ycombinator.com should also suggest that, but if this site moved to [https://hacker-news.example/](https://hacker-news.example/) I'd need to make the connection in my head to retrieve the password.

One important thing compared to WebAuthn, which has this behaviour built into it, is that the site owner doesn't know you use PwdHash and so their testing won't discover this problem, indeed they might insist it isn't a problem at all because it isn't part of their mental model of password behaviour.

Whereas in WebAuthn it just doesn't work, so even fairly light acceptance testing would discover that the new site can't re-use old WebAuthn credentials and that's a problem.

</comment></comment><comment><USER22> Needs year in the title: (2009)

<comment><USER23> I think it's more like 2005

<comment><USER24> Firefox 3.5 was dated 2009 and the page references it, so that's the latest verifiable date of activity that I can find (and I missed it except for the above comment).

<comment><USER25> Archive.org shows 2004. [https://web.archive.org/web/20040507195550/crypto.stanford.e...](https://web.archive.org/web/20040507195550/crypto.stanford.edu/PwdHash/)

That's the oldest it goes for this site.

<comment><USER24> The date isn't "when was this first ever posted on the internet", it's "when was this last materially updated in a relevant manner".</comment></comment></comment></comment></comment>


"Summary of why Grammarly are predatory and you should avoid them" - <AUTHOR> https://twitter.com/sebmck/status/1104132993893904386 <comment><USER2> Ugh. He makes some good points, but the framing is incendiary. "Summary of the Grammarly privacy policy, and why you might want to be cautious" would be better.

<comment><USER3> Absolutely not. Spying on this level shouldn't be normalized with "be cautious". If anything, the framing is understated.

Obligatory 1984 reference: "Summary of telescreen functionality, and why you might want to be cautious."

<comment><USER2> I think you need to reread 1984. Telescreens _were used_ to spy on the populace. That's more than _potential_ indicated by overly broad language in a privacy policy. No one's made the case that Grammerly _is_ spying, hence "predatory" is inflammatory.

<comment><USER3> "No one's made the case that Grammerly _is_ spying"

According to their privacy policy and the twitter reply ("Grammarly does not store all processed text, we do not use text to do anything but provide and improve our service"), they keep at least some of the text.

So they log your text, but it's not spying - so when does it become spying? When the first warrant is served? And when that happens, will it not be spying because "you agreed to it by using the service, it was all spelled out in the 'overly broad' privacy policy"?

</comment></comment></comment></comment><comment><USER4> Grammarly's response: [https://twitter.com/Grammarly/status/1104504155991793664](https://twitter.com/Grammarly/status/1104504155991793664)

<comment><USER3> Correct me if I'm wrong - doesn't that response basically say "Our policy lets us do all the things you listed, but we totally won't, trust us lol"?

And of course yes the cops can read all of it, but "only if the warrant is totally legit".

And warrant requirements are a poor defense: [https://www.popehat.com/2014/07/15/warrants-bulwark-of- liber...](https://www.popehat.com/2014/07/15/warrants-bulwark-of-liberty-or- paper-shield/)

</comment></comment><comment><USER5> "Summary of why [most chrome extensions] are predatory and you should avoid them"

Any extension can auto-update to change whatever they want, especially when already given the "Access your data on all websites" permission.

Browser extensions are a security nightmare.

</comment><comment><USER6> I haven't tried the grammarly but how else could they serve the purpose if they wouldn't get the text, fix and send it back? I think that's the core feature of the product itself.

<comment><USER7> I think the author's main point is that they save all the text on their servers indefinitely.

Also back in the days you did not need to send all your data to a server in order to do some processing on it and I believe Word still has an built-in grammar/spell checker that works just fine without all your documents being sent to Microsoft.

<comment><USER8> Yes, this annoys me.

Yes to use their service I need to send them text, they can't process it if I don't although it would be nice if they offered an offline app, even at a price.

However it's annoying how they store documents and try to be a document management / basic authoring system to, I see no reason why they should need to store documents.

It also seems they are missing a trick. If Grammarly opened up their API's, there are so many integrations that people can freely write and drive more paying Grammarly customers. At the moment I copy and paste from my text editor into Grammarly and back out! I never installed the browser extension for the same reasons the originally twitter poster mentioned, i selectively copy and paste in to the app.

<comment><USER9> > although it would be nice if they offered an offline app

They have a plugin for MS Office and probably some other word processors.

</comment></comment></comment></comment><comment><USER10> I saw today someone had Grammarly installed during a conference call. They were entering HIPAA-protected data into an internally-managed Jira instance, which presumably was being vacuumed directly up into Grammarly's database.

This might be a much bigger issue than I had considered :(

</comment><comment><USER9> IDGI... this is what Grammarly is supposed to do. Take your text and fix grammar/spelling/etc. How are they going to read your text if you don't send it to them? IANAL but I'm fairly sure they can't steal your copyright and if you're worried about them keeping data on you, then I have news about the rest of the internet you are not going to like...

<comment><USER11> They could read your text, provide their service and then discard it. Instead, they store it indefinitely. He states this explicitly right here [https://twitter.com/sebmck/status/1104132997110878208](https://twitter.com/sebmck/status/1104132997110878208)

</comment></comment><comment><USER12> Whats a good alternative?

<comment><USER13> A high school level English class?

<comment><USER12> I mean, this is just an unnecessarily mean comment.

Not everyone has the luxury of going to high school in an English speaking country. Not everyone is strong in English but still need to write properly.

Thanks though.

<comment><USER13> If you watch Grammarly's advertising, the core market seems to not be English language learners but college graduates that are having a hard time deciding between the usage of "were" and "we're".

[https://www.youtube.com/watch?v=Ak-Y56SfkS0](https://www.youtube.com/watch?v=Ak-Y56SfkS0)

Snark aside, there are plenty of English grammar resources that can be consumed in book form or online without attending an American high school or compromising your privacy. A solid one is the Chicago Manual of Style:

[https://www.chicagomanualofstyle.org/home.html](https://www.chicagomanualofstyle.org/home.html)

<comment><USER12> This isn't the type of stuff Grammarly helped me with. Passive voice misuse is still extremely difficult for me to catch. Even after learning about it multiple times.

</comment></comment></comment></comment></comment><comment><USER14> Google gets everything I type on Android, am I correct?</comment>


Ask HN: What is your favorite system for static website generation? - <AUTHOR>

Do you use a static website generator other than Jekyll or Hyde?  And if you use Hyde, what are your thoughts on new version (v0.8.8 https://github.com/hyde/hyde) compared to "classic" (v0.5.3 https://github.com/lakshmivyas/hyde)? <comment><USER2> Pelican ([https://github.com/getpelican/pelican](https://github.com/getpelican/pelican)) is a great static site generator. I really like the power of content metadata. The plugins are good, and development is ongoing. To top it off, the users on IRC are friendly and helpful. I'm sold.

</comment><comment><USER3> I love djangothis, [https://github.com/amitu/djangothis](https://github.com/amitu/djangothis). [http://amitu.com/2013/09/djangothis-for- blogging/](http://amitu.com/2013/09/djangothis-for-blogging/).

I am biased because I built it, but if you like jekyll, but prefer django/python, you should give djangothis a try.

</comment><comment><USER4> I'm using one I wrote myself. I'm not sure if it makes sense to ever release it, seeing that there are already over 9000 more mature generators out there, but I'm trying to solve some problems I've had with others, which mostly are:

* A simple interface (Unlike e.g. Pelican, which uses Makefiles to prettify it's command line interface)

* A sane template engine (Basically ruling out anything Ruby. Jekyll's Liquid engine for example only provides includes, no template inheritance)

* No unnecessary large dependencies like requiring Django

* Freedom of choice (I want to use YAML and Markdown)

* Tightly coupled asset pipeline

* Enough building blocks to quickly solve most usecases

* Should easily be usable on Windows (No makefiles please, no compiler necessary to install)

* Pluggable theming and extension support

Most newer generators solve most of these problems. For some reason most of them are written in Ruby though, which to my surprise has very popular template engines which don't even provide template inheritance.

</comment><comment><USER5> Hakyll ([http://jaspervdj.be/hakyll/](http://jaspervdj.be/hakyll/)) ist pretty sweet if you know Haskell.

<comment><USER5> PS: It uses Pandoc, which is big plus for me and might be for you too.

</comment></comment><comment><USER6> I use Nanoc for [http://illuminatedcomputing.com/](http://illuminatedcomputing.com/). I tried Jekyll first, but I didn't like using Liquid. Instead I write the templates in Haml and the content in Markdown.

<comment><USER7> +1 for Nanoc. I tried several before settling on this and I'm quite happy. It's simple, but fairly powerful and easy to extend.

</comment></comment><comment><USER8> Flask with FrozenFlask provides a nice framework to roll your own. Which is what I've done for every site I ship.

</comment><comment><USER9> I use Mynt [ [https://github.com/Anomareh/mynt](https://github.com/Anomareh/mynt) ] - it's got a small community of users, but the primary author is active and responsive. It uses python and sass.

</comment><comment><USER10> I wanted to build my own for my website, so here it is, a command line tool released as an npm package: [http://thibaultcha.github.io/Equiprose/](http://thibaultcha.github.io/Equiprose/)

\- It's using Jade and Stylus for templating.

\- It's a commande line interface.

\- Natively supports emojis, a la GitHub.

\- YAML for configuration and Markdown for redaction.

\- You can create as many websites as you want, they can all be configured differently and be served on test servers or build to their output directory.

</comment><comment><USER11> I use Jekyll for [http://markwatson.com/blog](http://markwatson.com/blog) and I generally like it. I used blogger (mapped to a subdomain) for years and liked it but decided I wanted more control over my own "property". Before using Jekyll I tried a cheap Wordpress host for a few months. Wordpress is OK, but had a lot of ceremony for what I need, and static web page generation was a good fit. I also like the Jekyll tools for producing nicely formatted program listings for a variety of languages.

</comment><comment><USER12> It's an oldie but I still use Template Toolkit for building most of my static websites - [http://www.template-toolkit.org/](http://www.template- toolkit.org/)

</comment><comment><USER13> Started getting into Assemble ([http://assemble.io/](http://assemble.io/)) since I've been digging deeper in Yeoman + Grunt + Bower lately.

</comment><comment><USER14> Middleman ([http://middlemanapp.com/](http://middlemanapp.com/)), easy to setup and deploy and uses Ruby.

</comment><comment><USER15> I like Cactus ([https://github.com/koenbok/Cactus](https://github.com/koenbok/Cactus)) and PieCrust ([http://bolt80.com/piecrust/](http://bolt80.com/piecrust/)). They are both super flexible and have met my static generator needs nicely.

Haven't tried Hyde or Jekyll.

</comment><comment><USER16> My favorite is Simplpost: [http://simplpost.com/blog/what-is-this- thing/](http://simplpost.com/blog/what-is-this-thing/)

It's not a command line tool, but it makes nice responsive static sites. And it's easy enough for my girlfriend to use. That's why I built it.

</comment><comment><USER17> emacs org mode converted to html using org-publish. [http://orgmode.org/worg/org-tutorials/org-publish-html- tutor...](http://orgmode.org/worg/org-tutorials/org-publish-html- tutorial.html)</comment>


Thank you, HN - <AUTHOR> http://h-s.io/notes/hn.html

<comment><USER2> Spectacular. How'd you do on conversions?

<comment><AUTHOR> Thanks. Conversions come from relatively small amount of visitors but overall orders are getting placed pretty fast and I am more than satisfied with the results.</comment></comment>


Show HN: Molten, a modern API framework for Python - <AUTHOR> https://moltenframework.com <comment><AUTHOR> I've been working on this for a bit now and decided to release it to a wider audience today. It's early days but really enjoyable to work with (I think so at least :P). Would love to get your feedback!

</comment><comment><USER2> I played around with it and molten is awesome. Still not sure, whether type hints are pythonic or not, but this gave me another tilt towards finding it perfectly suitable, especially for the web dev use case.</comment>