mieko

There's still a decent size contingent of non-technical people that look at exampleapp.com the way I'd look at wellsfargo-online-banking.com. I don't blame them: subdomains imply authority.

While I'm sure there's more, github.io, herokuapp and GAE/Appspot are the only services I know of following this practice, and they cater to a developer-level technical audience with the assumption that they'll work out a better name.

I think a plumbing-level security implementation detail should be a little less intrusive than having to move either the corporate domain or millions of user's addresses. I can't imagine Tumblr rolling out HPKP now with this workaround (though github did do the .com -> .io thing, so who knows).

The spec should've just included excludeSubDomains=

Here's an issue not mentioned in the article, which gives me the half-baked feeling about HPKP:

Thought experiment: (just using companies I think HN will be familiar with, I'm not involved with these.)

1. You're Tumblr or Basecamp or Slack with thousands/millions of user.example.com user subdomains

2. You want to protect all of them with a root HPKP policy with includeSubdomains, because users will be bouncing between them, and with that many trust-on-first-use gaps, it'd be pointless otherwise.

3. And then you want status.example.com hosted at StatusPage, blog.example.com hosted at Medium, and someapp.example.com hosted via GitHub Pages with a CNAME. Assume there are long-lived links to all of these subdomain URLs.

You can even assume that the third parties implement HPKP, and that they'll never have a hiccup.

There's no way to make this work without either:

A) Removing includeSubdomains, and no longer catch a large amount of cases as users traverse your site, barely solving a problem anymore

B) Serving a concatenation of every third party pin, opening up gaps huge enough where suddenly every CA is now authorized again, not solving a problem at all.

C) Noticing something I haven't.

And note that there are security (not merely vanity) reasons for using subdomains instead of paths for hosting user-generated content. I don't think this is too crazy of a scenario.

This is awesome. A few days ago I posted this question at the Qualys SSLLabs forum:

"Is there a reason for still having TLSv1.1 enabled?" https://community.qualys.com/thread/16565

Considering SSLv3 has been "dead" for a while now, and it still completes more handshakes than TLSv1.1, there's really no reason to keep TLSv1.1 around for most sites without very particular concerns. (But we're still holding on to TLSv1.0 until it's in the few-percent range.)

> Are you saying you're OK with co.uk getting a cert for foo.co.uk, even though they're under different administrative control?

This argument hasn't been made, or hinted at, by anyone, anywhere in this thread. And $50 isn't the difference between that being possible or not.

That's not how domain-validated wildcard certificates from any CA have ever worked, and it's not how any proposed wildcard-supporting future LetsEncrypt would work.

I can, today, get a valid certificate for myname.github.io (getting GitHub to serve it is a different issue, but from an MITM, proof of ownership, and CA/Browser Forum standpoint, it's properly assigned.) That's not surprising or weird, and it's exactly how it's supposed to work.

A certificate for myname.github.io does not give me a valid certificate for someone-else.github.io or github.io. Similarly, a certificate for '* .myname.github.io', which can also be procured today from dozens of CAs, doesn't cause panic or change the situation at all. I just can't get it from LetsEncrypt.

If I can only prove control of 'cs.mit.edu', I can get a certificate for '* .cs.mit.edu', but not all of 'mit.edu'. If I can prove ownership of 'mit.edu', I can get a certificate that covers '* .mit.edu'. This is how it should and has always worked. It just doesn't work via LetsEncrypt.

Basically, heavier authority moves right, never left, in wildcard certificates.

(Edit: HN eating asterisks)

This is the real issue with not allowing wildcard certs. If the rate limits were something that just cut in at abuse-levels, there'd be no need for them. Sites with per-user subdomains (to get security features like cookie isolation, break same-origin effects, etc) run into the limits really quickly, and must currently rely on a wildcard.

I've been calling this "the tumblr scenario", but people seem to think there's a way around it without just using another CA.

If I operated banking.io, I could get a bankofamerica.banking.io cert from LetsEncrypt today.

Unless something has changed, I could also get bankofamerica.com.banking.io, from LE or many other CAs. The wildcard issue has no effect on this situation.

LE uses the Public Suffix List to decide what's a "domain". Their really-low rate limits have caused a flood of applications which are overwhelming the PSL's maintainers.

https://community.letsencrypt.org/t/dyndns-no-ip-managed-dns...

ActionCable generators can now generate either JS or Coffeescript. This is relatively recent, but the direction is clearly toward decoupling.

https://github.com/rails/rails/commit/63ac6255ba3553b529f4b2...

> If you add a .bold class to an element, why would you want it to sometimes not be bold?

The problem is having a class called .bold, and then baking it into your HTML. I feel like many people arguing this have never undertaken a full-scale visual redesign on a large site. The designer comes in, and all the sudden everything marked .bold ends up meaning "lightweight italicized text". This presentational/semantic cycle repeats every 6 years or so, but I'm not sure where it's heading.

They're suggesting that Bootstrap-like classes that name and reference a specific visual rendering (e.g., col-md-hidden) are no better than the old ROWSPAN/COLSPAN mess. They've just moved from HTML attributes to being packed into the class attribute.

Then again, semantic markup was a huge pain in the ass before tools like SASS. Now you can actually name and categorize elements semantically in the markup, then decide what that actually means in the pre-processed CSS.

Edit: And it's true: Having recently gone through even a simple bootstrap-to-bootstrap redesign, we pretty much had to comb through every view and remove/replace non-semantic CSS classes. With SASS mixins and semantic markup, it'd have been a CSS-only change.

Legally, there is a huge gradient between length(work), sha(work), train(transcription(work)), transcription(work), thumbnail(work), etc. Your personal definition of "derived" sounds a lot like the mathematical definition, which isn't amazingly useful in a copyright context.

> Not sure about the legal definition.

Perhaps stating "You certainly couldn't release such a model under the GPL." so surely isn't a great idea?

I hadn't heard of the LG/webOS story, but it's a good read: https://gigaom.com/2014/08/28/a-failed-experiment-how-lg-scr...

"Intentional" was perhaps the wrong word for glibc, but BSD libc (at least on FreeBSD and OS X) actually document it as intentional:

    NOTES
    
    The fclose() function does not handle NULL arguments; they will result in 
    a segmentation violation.  This is intentional - it makes it easier to make 
    sure programs written under FreeBSD are bug free.  This behaviour is an 
    implementation detail, and programs should not rely upon it.

I thought I remembered similar wording for glibc, but I appear to have been mistaken.

I'd personally err on the side of clearer clean-up code, but this a good point (and a view shared with glibc and BSD-derived libcs that intentionally segfault in this case).

This is The Way To Do It. I take minor issue to calling free(NULL) abuse, though (I know you get it, but allow me to soapbox). I've known programmers who get squeamish relying on this, as if it's a hack, even though it's been mandated by the standard forever. It's like they believe someone would put together a fully-functional libc and miss that simple requirement somehow.

I think the C standard library would be easier to work with if they would've taken this further, and required, for example, fclose(NULL) to be a no-op.

I think, day-to-day, the Ruby object model can be as simple or as complex as you'd like it to be. Most dynamic or static OO languages have just as much complexity under the hood (vtables, doesNotUnderstand, metaclasses, etc). It has to be complete anyway, so it's made accessible, for better or worse.

I think you're more likely to run into it in the wild in Ruby because it's better exposed than most languages. When you see reflection or meta-object APIs in a lot of (typically not-as-dynamic) languages, it's sort of a "HOLY FUCK, WATCH OUT, I'M METAPROGRAMMING" flag. In Ruby, it's easier to daintily follow the white rabbit into the object model and care about the relationships you're referring to.

But on its surface level (class keyword vs. Class.new, def vs. define_method), I don't see it being any more complicated than similar dynamic languages.

When you say "puts 1+1" in a blank file, I can't imagine that not grasping that you're in a binding of an anonymous singleton instance of an Object named "main" being an hindrance. What's cool is, if you need to know, there's not a weird brick wall in your way.

FIPS is bureaucratic government red tape, and nothing else. It gives the "US Department of Whatever" and their contractors someone to blame when there's a fuck up.

No one respected in cryptography that I've met, or read papers from, would stand behind it as a seal that'd mean anything in actual security (please, someone, prove me wrong: I want to see SOME light in this tunnel). There are private entities with much more sensitive information than the U.S. Government, and the ones that take it seriously easily surpass FIPS (in purpose, not paper) with good engineering, because they can't hide behind a rubber stamp.

Not too long ago, I was on a team that was required to keep a FIPS-certified (FIPS 140-2) binary blob in production for months while there were known exploits against it. If you actually care about keeping amateur algorithms and implementations out of sensitive situations (vs. "Proving You Care via Paperwork"), you'd do better to follow Google or Facebook's security blogs than FIPS, because they react faster.

A few years ago, the Wolfire team (AKA, the Humble Bundle originators), put together a great set of articles on linear algebra as it applies to game development. I think it's one of the most plainly-written and practical guides out there. I still mentally picture the diagrams when I've been out of the loop for a bit.

http://blog.wolfire.com/2009/07/linear-algebra-for-game-deve...

I've seen Microsoft employees across the web have to point this out a dozen times.

"The New Microsoft" seems to be making better decisions overall, but it apparently didn't learn anything from the early-2000s ".net branding clusterfuck" which conflated their runtime platform, development tools, consumer-facing single-sign-on, and a few dozen other things in the mind of the public.

Most C++ platform ABIs are pretty trivial to recognize. A tool like this could distinguish a C++ binary by looking at its initialization/housekeeping sections, static constructors, __cxa_atexit, exception handling tables, linked libraries, etc.

For example, the Itanium C++ ABI (http://mentorembedded.github.io/cxx-abi/, perhaps Itanium's only real legacy) adopted by Linux/ELF and other platforms, leaves a huge amount of fingerprints on a binary. It'd take a very conscious effort, including hand-crafting linker scripts, to generate a C binary that a tool would incorrectly think was C++.

This is all true. The first thing I built was an awesome hammer, and I had a large amount of nails to deal with.

In retrospect, I'm sure there was a good deal of more focused, surgical solutions that'd save some overhead.

Author here. Here's the corresponding proggit thread: http://www.reddit.com/r/programming/comments/2hisfk/breaking...

Yeah, for this scheme to work, a locked phone would need to be a brick, short of desoldering the flash. Unauthenticated recovery modes destroy this.

I can see a scheme where each device has a specific unlock/recovery keypair in its keychain out of the factory (or first activation). It could be requested from the manufacturer from the service center. This would at least have accountability ("AT&T Store #451, Employee #8 requested unlock key for Device #123456").

The manufacturer's service could deny the request if the phone was reported stolen, or contact the rightful owner via other channels before releasing it. Or just revoke access to service centers with a history of abuse (e.g., the thieves have an "guy" at a strip mall).

As ineffective as biometric unlocks (TouchID, etc) are in targeted data retrieval scenarios, I'd wager their wider adoption would effectively kill casual smartphone theft.

Every 5S owner I know actually uses TouchID. I'd guess around half of the 5/5C users I see bother to use the four-digit PIN, because it's a longer process to unlock.

Smartphones unattended on a bar will be a less attractive target when the default assumption is that it's locked, and would be a large undertaking to put it into a state useful for the thief's personal use or resale. Making locking convenient enough that everyone does it (and the phone's physical security strong enough that it's an actual ordeal to bypass) would build a herd immunity for smartphone owners.

I've implemented a handful of simple dynamic languages years ago, and something I was interested in trying, but never did, was taking advantage of the MMU to replace guard clauses.

For example, mapping a few pages for vtables/method dictionaries read only. When something like `def` or `define_method` comes along, catch the segfault (which in this case would actually mean "segmentation fault" instead of "I fucked up") and rewrite all JIT blocks or method caches that depend on that method table. Once everything has settled, generally after startup and the vtables tend to stay more stable, the overhead seems like it'd be negligible.

jquery-turbolinks as a drop-in fix worked great for my application. The only tweaks my own code required at that point were resources I assumed would die and be recreated on the next page load, like doubling up setInterval handles in domready.