Brick. Webfonts that look good - <AUTHOR> https://github.com/alfredxing/brick

<comment><USER2> Comparison:

[http://brick.im/preview/brick.html](http://brick.im/preview/brick.html)

[http://brick.im/preview/google.html](http://brick.im/preview/google.html)

On firefox on osx, I see:

\- better kerning (space between L and o in "Lorem")

\- better definition in some letters (like the l in "elit")

\- cool stuff like ligatures (f and i in "overfilled")

\- and swashes (the Q in "Quisque").

Great work! I'm consistently annoyed but how much stuff google fonts are missing and how slow they are to update their fonts to the newest versions. Crimson Text comes to mind.

<comment><USER3> Out of curiosity, why are ligatures considered good? I commonly notice them in print because it catches my eye and hinders my scanning. Is it just because I am adjusted to digital media that commonly lacks it and the surprise factor is outweighing some other benefit?

<comment><USER4> _Out of curiosity, why are ligatures considered good?_

Ligatures are just single glyphs that represent multiple letters (or their equivalents). So for example the classic 'fi' pair is often turned into a ligature as I'll discuss below, but the ampersand symbol '&' is also a ligature (it originally came from the Latin word _et_ , meaning "and", although in many fonts today a much more stylised form is used).

In languages like English, ligatures are basically useful for two things: decoration (usually in slightly quirky fonts going for a certain stylised look, rather than everyday typesetting) and tidying up clashes between adjacent letters.

The 'fi' pair is an example of the second type. In classical typefaces designed for printing, the 'f' would often have quite a long overhang at the top. That worked fine when the following letter was something low like an 'a' or 'o'; you'd just close up the spacing a little, perhaps allowing the top of the 'f' to reach over the next letter a little, and everything looked lovely.

Unfortunately, if the following letter was something tall, like an 'l' or a dotted letter such as 'i' or 'j', this left the typesetter an unwelcome choice between moving the letters further apart (creating an awkward space in the lower half) or keeping them close together (creating a dense area or even touching/overlapping symbols in the upper half). Either way, the result tended to be distracting when set at typical body text sizes. So, ligatures like a combined 'fi' were adopted as a solution, in that particular case following the spacing and general shape of the original letters but slightly adjusting the top area to avoid the clash.

Unfortunately again, at some point the idea that using such ligatures was automatically a good idea caught on, and instead of serving a useful purpose (fixing clashes in fonts where the design of the font created a clash) they became something supposedly desirable for their own sake, one of those examples of typographic snobbery that just won't die.

That means today we see them not only where they are genuinely useful but also where they've been forced artificially. For example, you'll get a sans serif screen font where the regular 'f' has a short overhang and would quite happily sit next to a normal 'i' or 'l' with no problems, and then someone comes along and creates a distorted 'fi' ligature for it where the 'f' is extended and then clumsily wrapped into the dot over the 'i', even though there's no reason to do that and actually it distorts the shaping and reads worse than the original.

The other common mistake is to try and use techniques that work at body text sizes (where the useful kind of 'fi' ligature is a minor adjustment that should go unnoticed by a typical reader) and apply them at larger sizes for things like headings or pull quotes (where the adjustment becomes a big, obvious distortion when scaled up). In most cases, text set at large sizes would have been just fine with the original 'f' and 'i' glyphs and perhaps a touch of extra spacing, but sadly modern digital typography often lacks the hand-finished refinement that the old masters used to produce (at least in my rose-tinted view of history), because it's just too much extra work to fine- tune everything.

And thus we get things like the example here, where perhaps the ligature has been applied at a size a little larger than it really suits, and so you get what looks like an 'h' in the middle of the word and to some readers it then becomes the very distraction it was supposed to avoid.

<comment><USER5> > this left the typesetter an unwelcome choice between moving the letters > further apart (creating an awkward space in the lower half) or keeping them > close together (creating a dense area or even touching/overlapping symbols > in the upper half).

i just want to clarify that when it came to classic printing, the problem was much more pragmatic than aesthetic. The top of the f actually extended beyond the horizontal bounds of its sort[1]. If you didn't use a ligature, you risked damaging either your /f or your /i, but almost certainly you'd notice it when the line didn't pack flush. The the ligature was partly aesthetic, but it existed historically to make the act of printing work easily.

Now that kerning is better supported, 'historical ligatures' are something of a luxury, which is why they're still an opt-in feature in opentype fonts (you can see this distinction, btw, in the `rlig`, `dlig`, `liga`, `clig` and `hlig` opentype features[2]), except for brick, which is opinionated about these things.

[1]: [http://commons.wikimedia.org/wiki/File:Metal_type_kerning.sv...](http://commons.wikimedia.org/wiki/File:Metal_type_kerning.svg) [2]: [http://en.wikipedia.org/wiki/List_of_typographic_features](http://en.wikipedia.org/wiki/List_of_typographic_features)

<comment><USER2> Nah, I think they're just enabled here by default to show them off. You can fiddle with them with CSS3 font-feature-settings properties: [https://developer.mozilla.org/en-US/docs/Web/CSS/font- featur...](https://developer.mozilla.org/en-US/docs/Web/CSS/font-feature- settings)

<comment><AUTHOR> In a way, yes. All settings can be controlled through CSS, so tweak to your liking!

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Brick is a free and open source webfont service that serves fonts in their original form for beautiful rendering and full feature sets (kerning, ligatures, etc.)

Site: [http://brick.im](http://brick.im)

GitHub: [https://github.com/alfredxing/brick](https://github.com/alfredxing/brick)

Usage: [https://github.com/alfredxing/brick/wiki/Usage](https://github.com/alfredxing/brick/wiki/Usage)

</comment><comment><USER6> I dunno. On OSX in Chrome, at least, they look absoutely identical except for the 'fi' ligature, and the "E" in "Etiam" is kerned one pixel tighter, and there are maybe 3-4 other spots where there is 1px difference of kerning.

I've got a sharp eye, but at 300k for Brick, vs 92k for Google Fonts, I've got to go with Google Fonts here, especially when I'll usually have a given Google Font cached anyways, so it's often 0. But I'm glad to be given the option, regardless, and the opportunity to compare.

And as for character sets, Google Fonts lets you pick the character sets you want, too. Does Brick provide any characters which Google doesn't allow you to add?

<comment><USER7> Speaking of the cache and download sizes, when I reload the Google specimen the font files return a 304 (not modified) status while the Brick ones return a 200 code and have me download the files all over each time.

So for me it's 300k each time the page loads (Brick) vs 92k for the first page load and ~0 each time after that (Google).

Is this just me?

</comment></comment><comment><USER8> You can request all subsets to include a font's ligatures with Google fonts.

See: [https://developers.google.com/fonts/docs/getting_started#Sub...](https://developers.google.com/fonts/docs/getting_started#Subsets)

So if you add a `&subset=all` to the example page requesting from Google Fonts, they'll end up looking pretty much the same (though I think some things are missing in the example, like the swashes on the Qs).

I discovered this in reading the Lobster font's documentation.

</comment><comment><AUTHOR> I want to give a big thank-you to the fine folks at Fastly ([http://www.fastly.com](http://www.fastly.com)) who generously agreed to host Brick on their great CDN network. They're big fans of open source!

<comment><USER9> I think that should be www.fastly.com ?

<comment><AUTHOR> Yep. I'm still locked out with noprocrast so while I can add comments, I can't edit. 5 more minutes...

</comment></comment></comment><comment><USER10> What the heck is with the bottoms of the lowercase a, w, and t? Is it really supposed to dip below the line like that? And is the fi really supposed to join up in this font, or are they just overlapping and it's a happy accident that it looks like a ligature?

Overall it looks quite a bit heavier. I can see that working sometimes but not always.

<comment><AUTHOR> Is this on Firefox? Seems to be an issue.

I'm pretty sure the fi is supposed to be joined; if you highlight it with your mouse, it highlights as one character (though on copy-and-paste it's two, as expected).

OpenType fonts usually look a bit heavier, but I don't think it's a big issue.

</comment></comment><comment><USER11> Alfred, love the project and effort. Everything looks great on my Mac.

On a current Windows 7 machine, Brick is _much_ better than Google web font using Chrome, but both FF and IE v11 would be a show-stoppers for me, with random baseline shifts in the preview header making it look a little like a ransom note font.

Is there any browser compatibility lost by offering up only the WOFF format?

<comment><AUTHOR> Thanks!

Yes, IE <9 doesn't support WOFF (only EOT). For a compatibility table, see [http://caniuse.com/woff](http://caniuse.com/woff)

</comment></comment><comment><USER12> Alfred, I applaud the effort, but take a look at the baseline of /w/ and the stem of /a/ \- [http://imgur.com/O3QoCO8](http://imgur.com/O3QoCO8)

Top is Brick, bottom is GF, both rendered in Firefox 27 on Windows.

<comment><AUTHOR> Thanks! Hmm, seems to be an issue. Renders fine in Chrome though, and there doesn't seem to be anything wrong in FontForge either.

I'll look into it for sure.

</comment></comment><comment><USER13> OK, the only difference is in the link to show the other sample and the use of Brick versus Google Fonts.

The ligature is nice. My eyes aren't good enough to notice kerning differences --but that may be because the HUGE difference between the two samples is the line spacing. Brick jams those lines together like sardines, and while Google Fonts goes at least somewhat overboard in the other direction, if I had to choose, that so-tight-it-squeaks line spacing makes Brick painful to read.

UPDATE: Whew, thanks! _Much_ better. I'll have to take a look and see what changed.

</comment><comment><USER14> Why do the demo pages have different styling (esp line-height, it looks like).. makes it harder to see differences in two different windows.

<comment><AUTHOR> Sorry about that! It's probably a difference between the fonts served by Brick and those by Google.

Just pushed the commit, should be fixed now.

</comment></comment><comment><USER15> On Windows Firefox "Vestibulum" is kerned the same between the fonts. Brick is a bit heavier and they both user subpixel rendering.

On Chrome, Brick kerns "Vestibulum" better. Brick is the same weight as Google. But Brick does not use subpixel rendering while Google does.

On both browsers there was no difference in the kerning of "Lorem".

</comment><comment><USER16> Google fonts look better to me (Chrome, Windows)

<comment><USER17> Agree - especially the uppercase K and the lower case t. (Switching between between the two tabs in Chrome on Windows 7).

</comment></comment><comment><USER18> The kerning between 'V' and 'e' in 'Vestibulum' is very obvious: [http://brick.im/preview/brick.html](http://brick.im/preview/brick.html) versus [http://brick.im/preview/google.html](http://brick.im/preview/google.html)

</comment><comment><USER19> Only woff means no support for IE8 and the Android browser (<4.4). I checked on my Android 4.1.2 stock browser, the fallback is regular sans-serif. I guess, this type of progressive enhancement is acceptable.

That being said, this information should be explicitly presented (even highlighted) on the site, IMO.

<comment><AUTHOR> I'll put that in the GitHub usage wiki page.

</comment></comment><comment><USER20> I think I dislike the Brick version just for that ugly Q thing that takes up half a word, but it seems less bold and clear as well on Chrome on a Mac here. I often hear the Mac OS causes this sort of thing anyway, though, where "improved" fonts don't look much better in other web projects as well.

<comment><AUTHOR> You can disable swashes with a line of CSS: `font-feature-settings: "swsh" off;`

Of course you'll need to add vendor prefixes.

</comment></comment><comment><USER21> Congrats, font rendering looks Awesome on Chrome (win7), miles ahead of Google Fonts (which honestly, sucks on Chrome, and made me lose an entire day searching for why webfont rendering looks so so bad on Chrome). Again, thanks a lot!

</comment><comment><USER22> I like what you're doing, anything to improve typography on the web makes the whole experience better no matter what the design.

Is there any way I can use JavaScript to pick swatches or set options like the type panel in illustrator?

<comment><AUTHOR> The features available in the OpenType panel should also be available through CSS's font-feature-settings property: [https://developer.mozilla.org/en- US/docs/Web/CSS/font-featur...](https://developer.mozilla.org/en- US/docs/Web/CSS/font-feature-settings)

</comment></comment><comment><USER23> So these are slightly better versions of fonts already on [https://www.google.com/fonts](https://www.google.com/fonts) ? At first glance I thought you were offering new ones.

<comment><AUTHOR> I chose 10 of my favourite open source fonts; some are on Google Fonts, others (like Latin Modern) are not.

</comment></comment><comment><USER24> Heh, they both look fine to me. I really couldn't see the difference... I'm a sucker for good design, but it seems my font style is in the incompetent zone.

<comment><AUTHOR> The most noticable differences (apart from the rendering) are the fi ligature in the title ("overfilled") and the Q feature (where the tail is extended past the first letter ("Quisque").

<comment><USER25> Kerning is also better on OS X (with Firefox, Chrome and Safari 6), but it's hard to notice on the demo pages because, for some reason, the text body in the _Google Fonts_ page is three pixels lower than in the _Brick_ version.

I glanced at the CSS but couldn't find the reason.

</comment></comment></comment><comment><USER26> They look identical in chrome on Linux, the "fi" looks better with google fonts but the brick version make the fonts look a tiny bit more plump and darker.

</comment><comment><USER27> Small but significant win for Brick on Chrome (32)/Linux for me.

Ligatures (nice), better weighting and nicer tracking all around.

Very nice.

</comment><comment><USER28> I thought you meant this first - [http://mozilla.github.io/brick](http://mozilla.github.io/brick).

</comment><comment> ezequiel-garzon If I understand correctly, Google Fonts may be used in commercial websites. Does the license vary between different fonts in this case?

<comment><AUTHOR> The fonts that are also in Google Fonts should have the same license; for the ones that are not, consult the license file in each font's directory, but all of them should be usable commercially.

</comment></comment><comment><USER29> How does one incorporate this into a webpage?

<comment><AUTHOR> Usage is at [https://github.com/alfredxing/brick/wiki/Usage](https://github.com/alfredxing/brick/wiki/Usage)

</comment></comment><comment><USER30> Cool. But how does that stuff work? Are there any "typefonts for dummies" materials?

<comment><AUTHOR> A reference for custom fonts via @font-face: [https://developer.mozilla.org/en-US/docs/Web/CSS/@font- face](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face)

</comment></comment><comment><USER31> As far as I can see; iOS renders it just fine in both implementations

<comment><USER27> iOS devices typically have a much higher DPI than a "normal" (though this is rapidly changing) screen.

Because of that fonts often look far better and "truer" to their original intentions, Macs/iOS have always favoured fidelity over legibility (when pushed) so it is perhaps not surprising they both look good.

</comment></comment><comment><USER32> cool! how do I request additional typefaces and/or contribute?

<comment><AUTHOR> For now, open up an issue on GitHub.

I plan on extending the contributing page on the wiki with pull request instructions soon.

</comment></comment><comment><USER33> Name reminds me of Designmodo's "framework", The Bricks:

[http://designmodo.com/the-bricks-addons/](http://designmodo.com/the-bricks- addons/)</comment>


How We Built USA Today's Election Night Maps - <AUTHOR> http://mapbox.com/blog/election-mapping-usatoday/

<comment><USER2> I've worked on real-time displays of election results data in a newsroom setting, so I know how much planning goes into something like this. This looks great!

</comment><comment><USER3> This is a great write-up.

I love seeing your thought process on how you tackled the project. The bonus playback of realtime results and the not preloading county data are two very good examples of problems that need solving when you take on a project like this. Super write up.

</comment><comment><USER4> I really like that map with overlaid discs representing the number of EV for each state. I think it's much clearer than the usual method of distorting the map to make each state's area proportional to its number of EV.

<comment><USER5> "each state's area proportional to its number" = that class of map is called a cartogram

</comment></comment><comment><USER6> <http://www.usatoday.com/election-2012/results/>

Broken here. Chrome and FF.

</comment><comment><USER7> I learned about this: R2D3:

> _Since it doesn't get bogged down with supporting legacy browsers without > SVG support, we switched over to R2D3 for versions of Internet Explorer less > than IE9._ <https://github.com/mhemesath/r2d3/>

It's that easy to provide IE support for D3?

<comment><USER8> IE9 works well with D3 without any work. For IE < 9, generally it was pretty easy, though we had to do a few extra things we needed to work around:

1\. remove the use of SVG groups which are not supported in VML (though I think r2d3 has had a recent update with some level of group support) 2\. Avoid selecting features paths by class (e.g. us d3.select('path') instead of d3.select('path.state') Class selectors just wouldn't work for us. 3\. for performance, we used only the most simplified geographic data in IE < 9 4) 4\. Avoid using d3.mouse for mouse location. Didn't work right in IE

</comment></comment><comment><USER9> How long did it take? Any idea how much the AP data feed costs?

</comment><comment><USER10> I was hoping for some code listings.

<comment><USER8> Sure, what are you looking for?

<comment><USER10> Less narrative, I guess, but I think that's just a different preference of meaning for "how."

<comment><USER11> Personally, I loved the narrative. Which I mention not to suggest you shouldn't want something else, but so that the authors know that people liked it as is.

<comment><USER12> I also found the narrative really helpful. We run some similar products around maps, it was interesting to see how they approached this!</comment></comment></comment></comment></comment>


Firefox exploit found in the wild - <AUTHOR> https://blog.mozilla.org/security/2015/08/06/firefox-exploit-found-in-the-wild/ <comment><USER2> How many PDF.js security vulnerabilities have been found so far?

A quick Google search found only four:

[https://www.mozilla.org/en- US/security/advisories/mfsa2013-9...](https://www.mozilla.org/en- US/security/advisories/mfsa2013-99/) (another local file disclosure)

[https://www.mozilla.org/en- US/security/advisories/mfsa2015-3...](https://www.mozilla.org/en- US/security/advisories/mfsa2015-33/) (needs to be "combined with a separate vulnerability" to be exploitable)

[https://www.mozilla.org/en- US/security/advisories/mfsa2015-6...](https://www.mozilla.org/en- US/security/advisories/mfsa2015-69/) (needs to be "combined with a separate vulnerability" to be exploitable)

[https://www.mozilla.org/en- US/security/advisories/mfsa2015-7...](https://www.mozilla.org/en- US/security/advisories/mfsa2015-78/) (this one)

It still is looking better than the plugin it replaced.

<comment><USER3> >It still is looking better than the plugin it replaced.

Exploiting a bug in a memory unsafe language is much harder than writing some JavaScript. It is also much less reliable and platform specific.

The real question is why the hell is Firefox not sandboxed?

<comment><USER4> If you enable e10s in nightly it is I suppose thats coming up eventually to a releaae near you

</comment></comment></comment><comment><USER5> I don't even want my browser to have a 'local file context', is there a way to switch such behavior off entirely until explicit permission is given?

All these extra bells and whistles added to browsers to allow websites to pretend they're 'native apps' should require a very large switch to be thrown from 'safe' to 'unsafe' whenever an application requests such a thing. And what a pdf reader has to do with javascript is a mystery as well. Systems that are too complex are almost by definition insecure.

<comment><USER6> Maybe run it inside a chroot jail? Hmm... that sounds like a good idea just on principle... there goes my morning. Of course, X11 is still a problem.

<comment><USER7> "making firefox less insecure": [http://marc.info/?t=141616714600001&r=1&w=2](http://marc.info/?t=141616714600001&r=1&w=2)

and for those who think lynx is a more secure alternative, read this thread: [http://marc.info/?l=openbsd- tech&m=140516601718662&w=2](http://marc.info/?l=openbsd- tech&m=140516601718662&w=2)

<comment><USER8> That flamewar there in the lynx thread sure looked fun :)

</comment></comment></comment></comment><comment><USER9> The lack of additional detail in this very sparse announcement really compromises users' ability to damage control effectively.

Would like to know if an installation is vulnerable if:

        1) If Applications, PDF is set to "Always ask"
        2) Ublock and/or privoxy are used
        3) Javascript is disabled
        4) pdfjs.previousHandler.alwaysAskBeforeHandling == false
        5) pdfjs.disabled == true

Also which advertising network and which Russian site would be helpful for blocklists.

<comment><USER10> Hi,

I reported this 0-day. It used a PDF.JS same origin policy violation to access local files. You should be safe because you have javascript disabled and pdfjs.disabled set to true. There's no way for the script to run. It was on a international news website operating from Russia. The exploit was not on an ad network. The exploit was simply injected on every news article page through an iframe. Therefore I assume the news site was compromised. It could have been deliberately injected by the website operators, but I highly doubt it. The exploit targeted developers or tech-savvy people. On Linux, it targeted the contents of the ~/.ssh directory and some other sensitive files. I should say that I am not a security expert and I came across this 0-day by accident.

<comment><USER11> Please identify the exact international news website. Was it rt.com?

<comment><USER10> No it was not. I'm not sure if I should mention which website it was (yet). The exploit is still active. I am trying to get in touch with them to get it removed.

</comment></comment></comment></comment><comment><USER12> Once again, this demonstrates that blocking advertisements is a really good idea from an InfoSec perspective. Ad blocking not only abates a nuisance, it's an important security measure.

cf [https://twitter.com/swiftonsecurity/status/62840155490772582...](https://twitter.com/swiftonsecurity/status/628401554907725824)

<comment><USER13> By that logic it's more like an argument for disabling JS entirely - there is nothing about this that's specific to ads, and the reporter has speculated that it was placed by an attacker and only disguised as an ad.

<comment><USER12> Not executing any JS is safer, sure, but that's beside the point. If you strive for absolute security, power off your computer and never touch it again. This is about what you can do to improve the situation without impairing usability.

An adblocker doesn't impact usability (in most cases, it improves it significantly, through lower page load times and less space occupied by non- content), but prevents the vast majority of malvertising. Blocking all Javascript blocks all of them, but makes the modern web nearly unusable.

<comment><USER14> Unfortunately, an adblocker impacts income of site owners. Otherwise, I would have used these programs since a long time, but now my conscience does not allow it.

<comment><USER15> Well, they can ask my conscience to not run an adblocker because otherwise it impacts their income. If it was just that.

But they cannot ask my conscience to open myself up to security issues because otherwise it impacts their income.

(note that I have read the rest of the thread and am aware that simply running an adblocker wouldn't have prevented this exploit)

(second note/disclaimer is that I do run µBlock, for the personal reason that I feel they also cannot ask my conscience to open my attention to energy- draining distractions because otherwise it impacts their income)

<comment><USER12> Note that uBlock can be configured to block third party frames, which _would_ have prevented the exploit

</comment></comment></comment></comment></comment></comment><comment><USER16> I find the first sentence fascinating, "Yesterday morning, August 5, a Firefox user informed us...".

I'd love to know more about this person and their skill set. How was the exploit detected and isolated? How did this issue get reported and resolved in s day?

Assuming the Mozilla way, I wonder what the bugzilla report will read when it comes out of embargo.

<comment><USER10> It's me. I discovered the exploit in the wild when I became a victim of it. Skill-set limited. I was able to identify it and understand what it basically does, but not much more.

<comment><USER16> Modest too, "The script triggered a file dialog showing it was trying to access a local file. I opened the Developer Tools and saw all kinds of other files being accessed, including my private and public keys. I nearly got a heart attack. I quickly revoked all SSH keys and started monitoring the requests to narrow it down before I submitted the bug ticket with all the information I had, including the exploit script that was executed."

Wow, lucky that it triggered a prompt. Thanks for the response!

<comment><USER10> You're welcome. Yeah, that's exactly how I feel.

</comment></comment></comment></comment><comment><USER17> If at all possible it would be worth naming and shaming the advertising network that is allowing this exploit through.

Why do advertising networks allow advertisers to exectue Javascript? What need is there for it?

Every time one of these exploits that use advertising networks is found, it just increases the value of blockers such as uBlock. Whether you accept adverts or not, you shouldn't have to accept javascript being executed on your machine that isn't from the site you visited.

<comment><USER5> The networks themselves rely almost exclusively on javascript nowadays so the websites have little choice, the ad networks then in turn pass some or all of this trust to whoever makes the creatives, which up until recently were quite frequently done in flash and are now sometimes in javascript.

Personally I think all ads should be served up in a totally passive visual format (png, jpeg, gif) and have no other attributes than a non-javascript link target. That would take care of almost all drive-by injection. But adnetworks serve up what their customers want and their customers want interactive ads because the click-through rates are higher and because otherwise the competition would be doing it and they go out of business.

Ad networks that do serve up javascript should at a minimum pull the script to their own server and audit the code of the script. Good luck with that though.

Fortunately it's easy enough to install an ad blocker and get rid of that part of the problem entirely but it would be nice if users without an ad blocker wouldn't have to worry about this.

<comment><USER17> I agree. It's actually the animation of the adverts that I find most distracting. Text, and/or a static image - not an animated gif would be fine. I would enable ad networks that could guarantee that is all they will serve up.

<comment><USER18> The distraction is the point. It's no use enabling only the ads that you're easily capable of ignoring.

</comment></comment></comment></comment><comment><USER19> I believe using "about:config" and setting "pdfjs.disabled" to "true" will neutralize the vulnerability, at least from the description they gave of it, but confirmation from them to that effect would be appreciated, especially for users stuck on the current (or older) version, as the download page acknowledges some might be:

 _Note: If you use your Linux distribution 's packaged version of Firefox, you will need to wait for an updated package to be released to its package repository_

It would be particularly scandalous if they knew that disabling pdfjs would suffice yet refused to mention it because they couldn't bear to see their precious CPU/memory-hogging scribd knockoff no one asked for being disabled by their users, in effect putting their grandiose vision of the browser-as-OS ahead of their users' security.

</comment><comment><USER20> Some more details would be helpful here. Specifically:

1\. If PDF files aren't set to open using Firefox's built-in PDF viewer, was the relevant system still vulnerable? (That is, if under Options->Applications, PDFs were set to something other than "Preview in Firefox", would this attack still work?)

2\. Which were the 8 popular FTP clients potentially affected?

3\. Was this specific case all that could be done or was it an example of a wider class of potential exploits? (That is, can we actually trust any sensitive credentials in _any_ applications on any system that has been running Firefox before today? And could we have disclosed other sensitive information that was held in well known local files?)

I do deal with sensitive details, and have access to lots of external systems run by various clients. If there is a real danger here then I need to act. If there isn't, then I would prefer not to spend the next 1-2 days of my time updating everything that could have been silently compromised instead of doing revenue-generating work, and worse, contacting every client I work with to notify them that their security may have been compromised and it's my responsibility.

<comment><USER5> I'm roughly in the same boat as you but what I don't get is if your work is that sensitive then why don't you run with at least ghostery, umatrix and adblock on your machine?

The last thing I need is to have to contact a customer to tell them their data might have escaped my desktop computer because I took my browser to some unsafe site.

Also: start your browser in a VM.

<comment><USER21> Rather than ghostery:

[https://www.eff.org/privacybadger](https://www.eff.org/privacybadger)

<comment><USER22> Not compatible with Firefox 40?

</comment></comment></comment></comment><comment> mike-cardwell I'll just chuck this old blog post of mine out there:

[https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sop...](https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_Attacks)

Specifically, the "Securing the Web browser" section.

[edit] Also worth mentioning is the stuff about smartcards on that blog post. You can steal my ~/.ssh/ and my ~/.gnupg/, but because I'm using a smartcard, it wont do you any good.

<comment><USER23> That's a great post. Very thorough. However, a couple of observations concerning some security issues you might not be aware of:

First, X itself is very insecure, so by allowing your web browser to share the same X server as the rest of your apps, you are making the rest of your apps more vulnerable.

Second, the so-called "Trusted" Platform Module you're using for extra entropy may itself not be very trustable, despite the name. So you may want to rethink that.

Finally, according to the vendor of the GPG smartcard you're using, "the software on this card is not available as free software due to NDAs required for certain parts."

That there are NDAs on parts of the card or the software (it's not clear which) makes the card suspect, and I don't see where I can get the source of the code (free or not) that's running on the card. An ideal smart card would, like gpg itself, have completely open and transparent hardware and software. I'm not sure if any of those kinds of cards exist, however.

That said, I'm sure all the security measures you're taking in sum make you far better off than the typical computer user, but there's room for improvement.

<comment> mike-cardwell Re X being insecure. Yep. People have brought this up in the comments of the blog post. It doesn't _reduce_ security by shifting it to a different user, and no, it's not as good as running under a VM. However it does give it _some_ extra protection. For example it would have protected your main users ~/.ssh/ and ~/.gnupg/ directories etc that this latest pdf.js vulnerability could have exposed.

Re the TPM, even in the worse case scenario where the TPM is totally evil, it can't _reduce_ the randomness on my system. It will either keep it the same or improve it. At least on Linux, where it is just one extra source of entropy on top of the other existing ones.

Re the smart card, that may be the case, but it's probably the safest one out there, recommended and pushed by the guy who wrote GnuPG.

It's worth noting that the blog post is 4 years old now.

</comment></comment></comment><comment><USER24> Since the vulnerability is in pdf.js, is the Tor Browser Bundle vulnerable?

<comment><USER25> the latest versions come with noscript, so not unless you explicitly enable javascript on that site

<comment><USER26> NoScript is installed but disabled by default. [https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEna...](https://www.torproject.org/docs/faq.html.en#TBBJavaScriptEnabled)

</comment></comment></comment><comment><USER27> Updating software shouldn't give a sense of security, instead use sandbox/cipher technologies more generalized, for firefox you could use firejail[0] or sandfox[1].

Or even more general approaches like subuser[2] or QubeOs[3].

Personally I use FF 28.x + Noscript + Adblock plus + Firejail 0.9.28-1 and I feel quite confident I won't get hacked by random attacks.

[0] [https://l3net.wordpress.com/2014/09/19/firejail-a- security-s...](https://l3net.wordpress.com/2014/09/19/firejail-a-security- sandbox-for-mozilla-firefox/)

[1] [https://igurublog.wordpress.com/downloads/script- sandfox/](https://igurublog.wordpress.com/downloads/script-sandfox/)

[2] [http://subuser.org/](http://subuser.org/)

[3] [https://www.qubes-os.org/](https://www.qubes-os.org/)

</comment><comment><USER28> It's awesome that Mozilla detailed exactly what the exploit did, even which file paths it searched for.

<comment><USER10> The exploit basically uploaded the contents of a bunch of sensitive files to some server. Besides uploading the full list of files in the User directory (not the contents of the files) it uploaded the contents of the following files:

Linux: /etc/passwd, /etc/hosts, /etc/hostname, /etc/issue, .bash_history, .mysql_history, .pgsql_history, .ssh/known_hosts, .ssh/authorized_keys _, .ssh /id__sa _, .remmina /_.remmina, .remmina/ _.pref, .config /filezilla/_.xml, .filezilla/ _.xml,_ pass _.txt,_ access _.txt,_.sh, .config/psi+/profiles/default/accounts.xml

Windows (in the User directories AppData/Roaming and Application Data): Subversion: config, servers, auth/svn.simple/* , auth/svn.simple/* .* SmartFTP: Client 2.0/Favorites/Quick Connect/* .xml Psi+: profiles/default/accounts.xml Notepad++: plugins/config/NppFTP/NppFTP.xml .purple: accounts.xml s3browser: * .xml, * .settings FileZilla: filezilla.xml, sitemanager.xml, recentservers.xml FTP Explorer: profiles.xml FTPRush: RushSite.xml FTPGetter: servers.xml FTP Now: sites.xml FTPInfo: ServerList.cfg, ServerList.xml GHISLER: wcx_ftp.ini Ipswitch: WS_FTP/Sites/ws_ftp.ini VanDyke: Config/Sessions/* .ini

<comment><USER29> Hi, I run the site [https://scriptobservatory.org](https://scriptobservatory.org), which scans the internet and keeps track of what JavaScript people are sent as they browse the internet. Could you drop me an email with a copy of the exploit script (OR a list of a few unique strings found in the exploit script)?

With that, I can search the history of what we've been sent to get a list of all webpages that this exploit has been seen on.

Email is scriptobservatory -at- gmail -dot- com or you can input it in the "Do you have a list of websites you want to be scanned regularly?" text box.

<comment><USER10> Cool, done!

<comment><USER30> Hi. I work as malware researcher in ESET. Could you please share sample and malicious URL? email: cherepanov [at] eset [dot] sk

<comment><USER10> Done.

<comment><USER31> Hi fukusa, I know a Russian website (not a news site, it is webdev oriented) that triggers some PDF error in Firefox 35 and does not do that with latest Firefox 39.0.3. I sent a bug report to owners 6 days ago (just because PDF errors on a webpage are strange) and they have not fixed it yet. Could you check this website? I can send you an URL the way you prefer.

<comment><USER10> I'm not a security expert. If you have a bug report you'd better report it to Mozilla here: [https://bugzilla.mozilla.org/](https://bugzilla.mozilla.org/)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> Well, sending some user files to Ukrainian server is a bug.

But sending hashes of your downloads to Google [1][2] is a feature, right?

1\. [https://support.mozilla.org/en-US/kb/how-does-phishing- and-m...](https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware- protection-work) 2\. [https://bugzilla.mozilla.org/show_bug.cgi?id=1138721](https://bugzilla.mozilla.org/show_bug.cgi?id=1138721)

<comment><USER26> The first page says: "There are two times when Firefox will communicate with Mozilla's partners while using Phishing and Malware Protection. The first is during the regular updates to the lists of reporting phishing and malware sites. No information about you or the sites you visit is communicated during list updates. The second is in the event that you encounter a reported phishing or malware site. Before blocking the site, Firefox will request a double-check to ensure that the reported site has not been removed from the list since your last update." That seems pretty reasonable. But the second one looks like it checks every executable file you download. Why isn't that mentioned on the FAQ?

<comment><USER33> It is? Same FAQ page you listed:

"When you download an application file, Firefox will verify the signature. If it is signed, Firefox then compares the signature with a list of known safe publishers. For files that are not identified by the lists as "safe" (allowed) or as "malware" (blocked), Firefox asks Google's Safe Browsing service if the software is safe by sending it some of the download's metadata."

<comment><USER26> I don't suppose I could just disable that part, without disabling the part I quoted above?

<comment><USER33> You can in about:config, just Google for it.

</comment></comment></comment></comment></comment><comment><USER34> All the comments thus far have focused on the un/reasonableness of the vulnerability, plus some potshots at FF.

I've not seen any discussion about how this exploit is targeting dev keys. I find that as a data point that we've turned the corner: The coder in this case decided to grab auth keys/passwords (with a presumably low rate of success).

As logical as it may be (without RCE, not much more they could have done with a higher rate of success), I don't think it'd have been done ten years ago.

Fascinating.

<comment><USER10> As far as I understand with this exploit it was only possible to read files, not write to them or compromise the targets in some other way. With that in mind, it makes sense to target keys. Because the keys are an indirect way to compromise new targets.

</comment></comment><comment><USER35> I guess now is a good time to change my ssh keys. _joy_

even though I don't use pdf.js, have ublock and a strong key password, I'm not risking it.

I have access to so many servers, I'd rather spend 30 mins changing keys than take the chance

</comment><comment><USER36> Yet another reason to use uBlock and NoScript.

previous discussion: [https://news.ycombinator.com/item?id=10020361](https://news.ycombinator.com/item?id=10020361)

</comment><comment><USER37> > Yesterday morning, August 5, a Firefox user informed us that an > advertisement on a news site in Russia was serving a Firefox exploit that > searched for sensitive files and uploaded them to a server that appears to > be in Ukraine.

Which russian website, excuse me? Why not share the name?

</comment><comment><USER38> Browsers are supposed to _browse_ that's all. More and more stuff like this will come up with HTML5/JavaScript and people will begin to wonder why the world is jumping through all the JavaScript hoops to build a web app that is essentially a rich client app when they could use tools that are designed for that. Are they more or less secure, neither, once you can touch the user's filesystem the risk is the same which is why it still baffles me that developers actually want to code in JavaScript and dozens of one off libs when they could use first class tools which are far better designed. Browsers are supposed to browse, that is _all_ they are supposed to do.

<comment><USER39> What is browsing, then? Read-only? Are forums browsing, or interactive apps? Where do you draw the line?

I'm all for less bloat, and I can't figure why would a browser double as a PDF reader, for instance, when a native app is invariably faster, more feature- rich, more customisable and more secure. However, it's difficult to draw a concrete line between plain browsing and web apps.

<comment><USER40> > I can't figure why would a browser double as a PDF reader, for instance, > when a native app is invariably faster, more feature-rich, more customisable > and more secure.

A native app is _less_ secure. They're all written in memory-unsafe languages, are not guaranteed to be up-to-date, and do not run sandboxed. Integrating a JS PDF viewer into the browser hurts performance, but it's more convenient (no separate app to open, can start reading before it finishes downloading), and much less likely to be a security risk.

<comment><USER38> >> A native app is less secure. They're all written in memory-unsafe languages, are not guaranteed to be up-to-date, and do not run sandboxed.

So how can we even trust the browser if native apps are always less secure according to you?

The exploit ran despite the sandbox if I understood it right.

<comment><USER41> I don't understand the reasoning here at all. Are you arguing that because sandboxes sometimes have holes in them that they aren't worthwhile?

</comment></comment></comment></comment></comment><comment><USER42> Semi off-topic: What does the security track record of Chrome's integrated PDF viewer (PDFium) look like? Should I make it Click-to-play or is it about as secure as any other part of the browser?

Edit: NVD does list a bunch of vulnerabilities with "PDFium" in them [1], and I guess there are a few more from when it wasn't called PDFium yet, but I'm curious as to how an expert would interpret these numbers.

[1] [https://web.nvd.nist.gov/view/vuln/search- results?query=pdfi...](https://web.nvd.nist.gov/view/vuln/search- results?query=pdfium&search_type=all&cves=on)

<comment><USER43> And even latest here [http://googlechromereleases.blogspot.co.il/2015/07/stable- ch...](http://googlechromereleases.blogspot.co.il/2015/07/stable-channel- update_21.html) \- 5 of them has pdfium

<comment><USER42> Guess I will click-to-play PDFium, like all other plug-ins. Thanks!

<comment><USER43> There is also [https://chrome.google.com/webstore/detail/pdf- viewer/oemmndc...](https://chrome.google.com/webstore/detail/pdf- viewer/oemmndcbldboiebfnladdacbdfmadadm) :)

</comment></comment></comment></comment><comment><USER44> time to start running everything in it's own container, i don't like the idea of docker for production, but i like the idea of docker for my desktop, i want to now run every single command in a container, i can run firefox in a linux container, eg. [https://bbs.archlinux.org/viewtopic.php?id=196327](https://bbs.archlinux.org/viewtopic.php?id=196327)

</comment><comment><USER45> The article claims this exploit leaves no trace, but what about Linux atimes (assuming you don't have noatime set)? Eg. if you found multiple shell scripts with similar access times when you know you haven't worked on them at the same time. If this is a workable method of detection then it would be a good idea to avoid accessing any potentially affected files until you have recorded full access times.

</comment><comment><USER46> These browser vulnerabilities have got me thinking that I should start browsing in a VM. Has anyone moved to this level of isolation? Steve Gibson on the last Security Now podcast said he's been experimenting with Sandboxie...

Sandboxie looks like a paid closed source solution, I'm not sure they give me a compelling value proposition over something like a light linux distro under VirtualBox.

<comment><USER47> I was for a while, using a W7 VM on VirtualBox. I hooked it up to the VPN interface so that if the VPN dropped, I wasn't leaking traffic and it couldn't access the local network or host machine without significant difficulty.

It was initially for minimising the risk of false positives while testing remote access from the network I was on at the time.

Probably not enough to be hacking NSA, but it quickly added layer of protection from leaking stuff.

</comment></comment><comment><USER48> I sit on the Firefox Beta channel; not seeing an update at the moment. Any word on the status of this?

<comment><USER48> Update: Just received an update to the latest Beta of 40.0. Haven't found the change log but assuming this was the reason.

</comment></comment><comment><USER49> This is why everyone should consider running their web browser in a subuser: [http://subuser.org](http://subuser.org)

</comment><comment><USER50> And this is why we need working sandboxing on the desktop.

<comment><USER33> If you enable e10s in Nightlies you will get sandboxing.

</comment></comment><comment><USER51> Great, I applied the update, and now I got "Couldn't load the XPCOM", and I assume I have to reinstall Firefox.

</comment><comment><USER52> Could this exploit also be used to write to files? I have a feeling that it probably could, and that makes it even scarier.

</comment><comment><USER53> This exploit made me change my Ubuntu mirror because after hours the updated package wasn't yet in my configured mirror (but was available elsewhere).

If you need it too, here's the list

[https://launchpad.net/ubuntu/+archivemirrors](https://launchpad.net/ubuntu/+archivemirrors)

</comment><comment><USER54> I am not security pro, but I wonder if server-side installations of PDF.js are exploitable? WordPress plugins using PDF.js, can these become a new vector to attack webservers? Case, site uses PDF.js plugin to render pDFs for users. Is it possible to access server filesystem through PDF.js?

<comment><USER43> There are not exploitable (at least not the same way). Firefox PDF viewer is a modification of PDF.js, so PDF.js code would run in the browser without a web server. The exploit might poke a hole in EMBED tag security of the web browser (and not in the PDF.js code itself). WP plugin shall be safe as any web application (unless it introduces similar security hole in its code, e.g. XSS).

</comment></comment><comment><USER55> Why the new version number is "39.0.3" ? Did I miss "39.0.1" and "39.0.2" ?

<comment><USER56> 39.0.1 and 39.0.2 fixed serious regressions in Firefox for Android in some configurations. They weren't security fixes.

<comment><USER55> Thanks, I didn't know the version numbers where global for every platforms.

</comment></comment></comment><comment><USER57> This is why I disable PDF viewing in any browser and have it send it to sumatraPDF instead

</comment><comment><USER58> Firefox's 'About' page seems to lack enough information here.

My page just said 'Firefox 39 available' and 'restart to upgrade'. But the exploit page notes that you need version 39.0.3 in order to be protected. So it's unclear if the upgrade would fix things or not.

<comment><USER59> Once you've updated, the About Firefox modal will show you the exact version number you're on.

<comment><USER60> Exactly, I had "Firefox 39 available", once I'd updated and checked "About Firefox", it's version 39.0.3

</comment></comment></comment><comment><USER61> Out of curiosity, how many users will be opening pdf using pdf.js? Is it widely used?

I was never comfortable with pdf.js and changed the setting to use the default pdf viewer in all my machines.

<comment><USER62> I uninstalled PDF viewers and always use pdf.js to view PDFs these days.

<comment><USER61> I guess pdf.js will be advantageous if you are using browser always.

Most of the times, I have multiple pdf files open side by side. So I had a pdf viewer in the machine.

</comment></comment></comment><comment><USER63> PDF.js reader can be disabled in Firefox by setting "pdfjs.disabled" value to _true_ in "about:config".

</comment><comment><USER64> For PDF, I never view pdf using browser, save it then open it using your pdf viewer.

</comment><comment><USER65> just more reasons to run ad blocking software

</comment><comment><USER66> That's what you get for making the web browser a platform to run applications.

</comment><comment><USER67> I wonder if Firefox is going to disable itself.

</comment><comment><USER68> Another good idea is to never visit news sites based in Russia. Not only you won't get infected with random malware, you also won't have to read blatant propaganda that passes as "news" over here.

</comment><comment><USER69> Why is anyone still using this browser anyway? Firefox is the new IE6.

<comment><USER5> Because it is the only browser that is not tied hand-and-foot to some major global commercial player, and because each and every browser ever launched had security issues.

Even lynx is not immune:

[http://www.cvedetails.com/vulnerability- list/vendor_id-5836/...](http://www.cvedetails.com/vulnerability- list/vendor_id-5836/product_id-9869/Lynx-Lynx.html)

<comment><USER70> > Because it is the only browser that is not tied hand-and-foot to some major > global commercial player

Not close to true. There are hundreds of browsers out there. I used Surf[0] and Xombrero[1] for a number of years.

[0] [http://surf.suckless.org](http://surf.suckless.org)

[1] [https://opensource.conformal.com/wiki/xombrero](https://opensource.conformal.com/wiki/xombrero)

<comment><USER64> thank you! first time I hear about xombrero</comment></comment></comment></comment>


Ask HN: DNS TTL - Why Not Small? - <AUTHOR>

When setting up my DNS parameters, I usually select my time to live as 86400 seconds.  I occasionally regret this decision, when I need to make a change.
I see in another thread, that Posterous sets their DNS TTL at 5 minutes.
So, my question is, why wouldn't I just always use a 5 minute TTL.  I assumed it was to be a "good internet citizen", I should leave it long.  Is this a valid concern, or can I, with clear conscience, reduce it substantially? <comment><USER2> The lower your ttl, the higher the traffic on your dns server. The more the load on the internet in general as other dns servers will have to query your server more often which might be slower because of the extra traffic.

There are reasons for low ttls... like your information changes quite often. I've managed tons of domains where the dns was basically setup and then never really changed. If it was going to change, we knew well in advance so we could do 48+ hours for a ttl.

If you need a low ttl do it, if you don't, be a "good citizen" and use a higher one.

</comment><comment><USER3> Because with a low DNS TTL and you get a DDOS attack like what happened at DNSmadeeasy, your sites go down in 5 minutes. Also a high TTL puts lower load on the DNS servers and increases response times.

All that being said, I still use a low TTL so that I can quickly switch servers in the event one goes down.

</comment><comment><USER4> One downside to short TTLs on hosts that receive mail is that if you have some sort of DNS issue for more than 5 minutes, mail may start getting rejected, because many mail servers treat hostname-not-found or no-MX-records-for-domain as a permanent rather than transient error, so bounce the mail and don't retry. With a higher TTL, there will be a greater period where the server has the wrong IP after a change, but that will typically result in a transient error, of the "isn't responding" rather than "doesn't exist" variety.

</comment><comment><USER5> Because a low TTL means that a reasonable % of page requests are going to see not only the latency of your DNS server, but also that of the shitty ISP's fetch store return cycle, which can result in a couple hundred extra ms on top of your page serving time. This extra bit of latency can make for a bad user experience, so they may not come back (every little bit counts).

Because ISPs are likely to ignore it anyways and impose whatever _they_ think is a good value.

</comment><comment><USER6> Shorter TTL's just increase traffic between caching nameservers and authoritative nameservers (<http://en.wikipedia.org/wiki/Time_to_live#DNS_records>). Because of this, some DNS providers set a limit on how low your TTL can go. Others charge for DNS queries over a certain amount.</comment>


CLPython, enables use of Python libraries from Common Lisp - <AUTHOR> http://github.com/franzinc/cl-python

<comment><USER2> _An implementation of Python in Common Lisp_

Does that mean it only supports pure Python libraries?

<comment><USER3> Yeah; it doesn't currently implement Python's C API.</comment></comment>


Pie Charts No Longer Considered Harmful - <AUTHOR> http://eagereyes.org/criticism/in-defense-of-pie-charts

<comment><USER2> No, the actual conclusion here is "for some simple problems, pie charts are more useful than bar charts or tables".

This does not show that pie charts are not lousy. It merely shows that they are not always the _lousiest_. Since tables aren't really much of a method of visualizing data and bar charts are almost as lousy as pie charts, this isn't saying much.</comment>


Why Markdown Is Not My Favourite Language - <AUTHOR> http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/ <comment><USER2> A lot of the author's reasons have to do with lack of a spec. This topic was brought up by Jeff Atwood (creator of StackOverflow) last year -- [http://www.codinghorror.com/blog/2012/10/the-future-of- markd...](http://www.codinghorror.com/blog/2012/10/the-future-of- markdown.html)

I had to build some markdown functionality into a project the other day, and so I googled around to see if there has been any update on this. Didn't find anything official, but a few random comments and blog posts here and there seem to indicate that StackOverflow, Github, and Reddit are working together to come up with a spec.

(Apparently John Gruber has disavowed any responsibility for leading the community in this regard, so now it's up to the big users of markdown to figure something out on their own).

</comment><comment><USER3> I was with him until he recommended one based on Wiki markup. Wiki markup is pretty universally reviled for good reasons.

He right complained about the heavyweight notation required for a simple link in Markdown, but everything is that bad or worse in most Wiki markup.

Really, the complexity of the markup you need depends on your application and any attempt to make a "one size fits all" markup is going to fail. The needs of a simple commenting system are vastly different from a user-editable CMS that doesn't want to give access to full HTML, but wants robust formatting options.

<comment><USER4> I am really happy to see this article. I was just talking to a friend about how much I dislike Markdown and how it has become the de facto markup.

Can you explain to me why wiki markup is universally reviled?

I find Creole to be great text markup. It feels really natural to use and it expresses the intended meaning whether it's rendered using HTML or displayed in plain text. I really like this statement by Christoph Sauer on the Creole website: <http://wikicreole.org/wiki/ChristophSauer>

I agree that Creole or any other formatting markup is not going to solve everyone's problems. However, I think that whenever Markdown is a good choice, Creole is a better one.

<comment><USER5> That statement is nothing special, both Markdown and asciidoc claim to be a formalisation of the plain text conventions you already use. IMHO most of the alternatives mentioned in this comment thread understand their goals and the design space well enough, and many are definitive improvements over Creole's MediaWiki-inspired, committee-designed syntax. They also win in featurefulness (Markdown and Textile have html embedding, asciidoc and ReST have extension mechanisms), which is important for a wiki.

</comment></comment></comment><comment><USER6>
        Stack Overflow supports an alternative syntax for
        this use case:

          Our primary landing page is <http://www.example.com>

        Again, this is not knowledge that the user can take
        with them to other Markdown based sites.

Actually, that _is_ part of the markdown spec. See: <http://daringfireball.net/projects/markdown/syntax#autolink>

<comment><USER7> The fact that the other ambiguity references a stackoverflow article suggests that the author may not have actually looked at the spec.

TBH the article reads like an elaborate advertisement for Creole.

</comment></comment><comment><USER8> Oh, he didn't mention half the stuff I thought he would. He's right about a lot of things though.

Take this for example:

        Hello world, there isn't
        1. There are 4.

The original markdown treats the second line as a continuation of a line in a single paragraph. Github treats the second line as the start of an ordered list. Why? Because then you can do things like this:

        # My list
        1. foo
        ...

I've been so torn about how to implement so many of these things. I've had a lot of people ask me about that particular issue, and when I tell them the original markdown behavior requires 2 newlines after a line before starting a list, it was the last thing they expected.

The main problem with markdown is not the fact that these counterintuitive things exist, but the fact that they're not consistently implemented. I've spent nearly 2 years trying to reconcile all these differences. See <https://github.com/chjj/marked> for more crazy markdown nonsense in the test suite.

<comment><USER5> Next time people ask, just explain that markdown always reflows consecutive lines.

GitHub's change (for comment fields only) isn't list specific, they just never reflow. They document it here:

[https://help.github.com/articles/github-flavored- markdown#ne...](https://help.github.com/articles/github-flavored- markdown#newlines)

<comment><USER8> Having newlines=line-breaks does not necessitate what I mentioned above. This is actually a common issue across multiple markdown engines, including ones that do not implement github's newline behavior. I suppose you can think of it that way logically, but I don't consider this a part of GFM since it is actually so easily mistakenly implemented. It _is_ list-specific.

If I did agree with you on this, I could edit my post and change "github" to any of a dozen markdown implementations that supposedly implement markdown accurately and it would be just as true.

But, like I said, GFM could obey the markdown spec with respect to the list and _still_ obey its own spec.

To explain this concept:

Why doesn't

        Four
        + Five
        + Six

Simply yield

Four
+ Five
+ Six

And instead yields

Four

Five

Six

It mistakenly thinks that line is a list - _that is the bug_ , not the newline behavior. You could have both behaviors at the same time without conflict. It could return the first output and still be true to the newline part of the GFM spec as well as the original markdown. Instead, it chooses to do something ridiculous.

<comment><USER5> The spec deviation for newlines could be done in multiple ways, but the implementations you mention all choose to trigger block constructs (which includes lists, and also headings) on any start of line. It's because the syntax tweak is intended to avoid confusing people with context-dependent syntax (syntax appears not to work if there wasn't an empty line before), not to give an alternative way to generate
.

</comment></comment></comment></comment><comment><USER9> My favorite text based markup language is asciidoc [1] because I think it has the best looking source text syntax [2]. The goal is to make it completely readable in plaintext and not super markup-y. If someone were to "less README.asciidoc" they should not even notice that it's markup--it's just a nicely formatted text file.

That said, it's really only made for documentation and is based on the Docbook XML toolchain which makes it an absolute bear to use.

And like all of these text-y markup languages, it has corner cases that don't work well.

[1] <http://asciidoc.org/>

[2] <http://asciidoc.org/index.txt>

<comment><USER10>
      > The goal is to make it completely readable in plaintext and not super markup-y.

If that was the goal, then I think it failed. I have used it in the past, and it has more weird rules and syntax than even reST. It is powerful though, I will grant it that.

</comment></comment><comment><USER11> Collapsing single newlines is a love-it-or-hate-it feature. Personally I like it because it allows me to place one sentence (or clause) per line, which makes version control much easier. But a lot of people seem to hate it with a passion, and I can also understand their frustration because it just isn't intuitive to anyone who doesn't already know how HTML treats whitespace.

Things that actually do annoy me from time to time:

\- In the default implementation, an underscore in the middle of a word causes the rest of the word, and everything until the next underscore, to be italic. Fortunately, most of the _actual_ implementations have fixed this, but that ain't standard. I also don't think Reddit has fixed it yet.

\- Using one asterisk OR one underscore for  and two asterisks OR two underscores for  feels redundant. There is no need for two different syntaxes to achieve the same effect. I would prefer one underscore for  and one asterisk for  (email clients have been doing this for plain- text emails for a long time), but maybe that's just me.

\- AFAIK there is no built-in syntax for underline, strikethrough, superscript, and subscript. Maybe we should repurpose some symbols to handle such cases.

On the other hand, there are things the article complains about that I absolutely don't think need to be "fixed":

\- HTML filtering/escaping. Seriously? There are plenty of excellent HTML filters in every language. No need to reinvent the wheel. Just pipe the stdout of your Markdown parser to the stdin of your HTML filtering library. In addition, some of us use Markdown to write our own blogs, where we have every right to insert an occasional


ProtonMail Bridge is now open source - <AUTHOR> https://protonmail.com/blog/bridge-open-source/ <comment><USER2> " ProtonMail Bridge is a desktop application that allows you to fully integrate your ProtonMail account with any IMAP and SMTP email client, including Outlook, Thunderbird, or Apple Mail. Open sourcing the code lets anyone verify how the encryption process takes place through Bridge as the emails are transferred between your ProtonMail account and your desktop email app."

</comment><comment><USER3> For anyone else wondering what this is, looks like it downloads encrypted mail from ProtonMail, decrypts it and exposes the unencrypted mail to your email clients as an IMAP server.

</comment><comment><USER4> And to think I was going to cancel my subscription because the bridge wasn't open source...

Not to mention that I missed the Linux support announcement: [https://protonmail.com/blog/proton-bridge-linux- launch/](https://protonmail.com/blog/proton-bridge-linux-launch/)

<comment><USER5> Great! I was using another open source bridge but it didn't support 2FA :/

</comment></comment><comment><USER6> This is really cool to see.

Hopefully I can debug why the Bridge pegs two cores and writes out 10gb+ of a single log line over and over when I try to transfer one particular email through it overnight. :-)

(same thing happens in the dedicated mailbox migration program, which is probably using the same shared libraries)

</comment><comment><USER7> I emailed them a while ago, to encourage pursuing an open standard for their protocol, such as through the IETF.

Open sourcing Bridge is helpful, and perhaps a step towards that.

Perhaps, with this reference, some other mail providers will implement the server-side protocol to Bridge, and some MUA developers will implement/integrate the client-side protocol.

</comment><comment><USER8> It would be great if someone forked this to allow it to function as an XOAUTH2 IMAP proxy for other providers.

This would be particularly useful with big e-mail providers (Google, Microsoft) looking at retiring password based authentication in the near future.

<comment><USER9> I've been curious about ProtonMail for a long while - my greatest hesitation is that I use multiple addresses and ProtonMail seems to be based around a single address. I'm not sure why email providers all want to charge per address - why not allow multiple addresses and charge for transit or storage? However at minimum multiple instances of this running could be a step towards multiple accounts.

<comment><USER10> They allow multiple addresses and domains if you pay for premium, its not per address but a monthly fee which includes the functionality of handling them. Their UI is actually really friendly for multiple addresses unlike for example gmail.

</comment></comment></comment><comment><USER11> The new book "The Infinte Game" has an idea of 'Just Causes', an idea that means business, organizations, or individuals have a long term and often not totally achievable goal, that is to benefit customers and society.

I think that ProtonMail has the Just Cause of protecting privacy.

<comment><USER12> Or they found a good market fit with privacy conscious customers and are going all the way. Either way, it's a win for the consumer.

</comment></comment><comment><USER13> Nice to see!

I'm on Gnome Linux and ProtonMail only mention Thunderbird in their docs, but I've made the bridge work with Geary too. Geary is a bit more simple and modern looking email client alternative. See [https://wiki.gnome.org/Apps/Geary](https://wiki.gnome.org/Apps/Geary)

Still I normally end up using the web interface for ProtonMail as it fits my workflow better and only need to have one tab open in my browser. They even have a nicer looking beta which also has an in-built dark theme at [https://beta.protonmail.com](https://beta.protonmail.com)

<comment> desktop-app > Still I normally end up using the web interface for ProtonMail as it fits my > workflow better and only need to have one tab open in my browser. They even > have a nicer looking beta which also has an in-built dark theme at > [https://beta.protonmail.com](https://beta.protonmail.com)

Btw, you can have both static beta web client and offline access to the email messages using [https://github.com/vladimiry/ElectronMail](https://github.com/vladimiry/ElectronMail) even being on free account as opposed to Bridge thing. The app also supports "persistent sessions" feature, unlimited full-text search (body content also gets scnned) and other fancy stuff.

</comment></comment><comment><USER14> Dang. That is encouraging that they can peruse an open source model.

</comment><comment><USER15> It looks like you still have to have a paid account to use this?

<comment><USER16> For those without premium accounts, I have good experiences with [https://github.com/emersion/hydroxide](https://github.com/emersion/hydroxide)

</comment></comment><comment><USER17> I applause ProtonMail services and initiatives, it can only be good for us.

However why did they develop anything specific? SMTP / IMAP already support secure connection (i believe). Or it could be encapsulated in a secure lower transport protocol.

Also I thought there were tons of GPG/PGP extensions for email clients already to read encrypted emails

<comment> kube-system IMAP, et al, require mail to be unencrypted on the server side; they are only encrypted in-transit.

<comment><USER17> Which is why Protonmail uses GPG/PGP for the encrypted ones, I believe. So there should be no reason that we cannot use any mail client with GPG/PGP support.

<comment> kube-system Their service does stuff beyond the basic functions of PGP. That is handled by the bridge, and wouldn't be handled by your favorite flavor of email client and PGP plugin.

One example: if you message another ProtonMail user, all of the PGP functionality is handled automatically. I don't think this would be possible with any other solution.</comment></comment></comment></comment>