kofalt

After using Netflix for quite some time, I have no evidence to support any hypothesis other than that their overall selection is secretly horrible and that they wish to conceal this however possible.

Evidence includes but is not limited to: Their user interface appears to intentionally border on unusable, a rambling Quora post by a C-level exec about how advanced search (a la Gmail) would ruin the world, and they've shut down their API, making it harder for third-party sites to index their selection, and allow positive UX to be possible thereby.

I don't know if it's reasonable to ask this, but it would be cool to have an option to swap them around?

I guess I'll always be assuming it behaves like Firefox, so I'm tripping myself up a lot.

Either way, very cool app.

The feature of being able to share a URL from my browser to Offline is pretty sweet.

I was irate that I had to type out URLs, until I thought to try that :)

Bug report: hitting the Back button takes me out of the browser, while the back arrow goes backwards in web history. I expected them to be the other way around (behaving more like a normal browser).

Yikes.

> What I am saying is that it is no longer fundamentally the same thing I was originally hired to help build nor is it compatible with my vision for the future.

I've heard elsewhere that 2.0 will be an entirely unrelated framework which will be still called Angular for no good reason.

Dismissing this opinion as a troll is no longer productive after the above commentary by an Angular developer.

According to Red Hat, the current best way to secure your Docker usage is to `127.0.0.1 index.docker.io` and use an alternate transport.

The core "translate flags into running container options" works fine IMO, it's the centralized transport causing the issue. Which isn't the end of the world, as distributing tarballs is not exactly a demanding task.

As an example / plug, I helped write a (prototype) tool that lets you import a docker image from the registry, then transport / version it separately: https://github.com/polydawn/hroot

Thus, integrating via `docker load` + `docker export` is possible & reasonable.

Linked from the article: https://securityblog.redhat.com/2014/12/18/before-you-initia...

Agreed. I try to explain sometimes that I'm merely tired of experiencing the same problem, over and over, for years.

I would like to experience the next problem, please. If only for variety's sake.

Shouldn't be terribly surprising: http://dayswithoutansslexploit.com

HTTPS might be better than getting a website in cleartext, but you'd have to be a madman to claim that HTTPS is safe, sane, or secure.

Which circles back to the "Javascript is hostile to cryptography" point the article makes; I welcome any expert-audited JS libraries that can accomplish secure file encryption, for example. But even assuming this blocker is overcome, any illusions are shattered by the F5 key.

As pointed out elsewhere in the thread, there are few attacks that allow you to listen in on an SSL connection's content without also allowing you to modify that content - say, with a version that pastebins your keys.

Hence my argument that JS cannot provide anything SSL lacks, plus or minus some wishful thinking. Combine this with the fact that it's impossible to protect against a MITM-modified JS payload (see the "chicken-egg problem" portion), and you have a rather uphill battle here.

> protection against the attack model of the passive eavesdropper

My argument would be that trying to protect against passive attackers with JS adds nothing beyond what SSL already offers.

Which is already required as a matter of course, and already compromises the payload if SSL is broken (again).

You're right to point out the difference between targeted and general attacks, but you're also misrepresenting the problem. An attack on SSL can take quite awhile to research and implement, but then can be used widely. One would expect the exact same scenario to play out with any javascript crypto library, as it does with all software.

So, yeah - if you rolled your very own library that's unique to this planet for exactly one website, congratulations! You're secure as long as there are no attackers! Doesn't really say anything useful about your security though. Or about the viability of using a fundamentally broken crypto platform to do crypto.

> assume a somewhat determined attacker

Most CVEs that come to mind assume a somewhat determined attacker.

It takes a reasonably determined attacker to commit to rails without permission [1] or run a ten-line perl script to crash a server [2] too.

Waving away a problem via "the bad guys would need to think for more than one second" is not exactly reassuring.

[1]: https://github.com/rails/rails/commit/b83965785db1eec019edf1...

[2]: http://www.ocert.org/advisories/ocert-2011-003.html