quinndiggity

"An analogy: there are open source versions of Dropbox for users that don't trust Dropbox with their files (NextCloud, ownCloud, etc.), however this comes with the friction of having to host your own solution. We are more like Dropbox, where we want to create a solution that is incredibly easy to install, manage, and work with."

NextCloud: self-host OR pay for a managed option (this means someone runs it for you.) ownCloud: self-host OR pay for a managed option (this means someone runs it for you.)

He compared it to Dropbox, Nextcloud, and ownCloud.

If ycombinator and their mods are more concerned with the promotion of one of their own investments, over discussion of its merits and feedback from the people who _would_ be the ones adopting and promoting it in their own companies if it indeed lived up to its own marketing, then I invite a ban for trying to keep hackernews honest and driven by community discussion, over a place for them to advertise, self promote, pat themselves on the back, and pad their wallets.

To be brutally honest (as if not already), Doppler makes me wonder why not simply focus on building on-top of open solutions like Vault. Considering there is no on-prem version of Doppler, you could essentially run Vault behind the scenes and provide the experience you are aiming to deliver with Doppler, giving you a marketing strategy for free ("Ready to run secret management with a focus on usability; the fastest zero to production option for 'Enterprise' secret management"), that doesn't require contrasting yourself ("We ARE Vault; it's a great tool, we made it easier"), and could even value-add or contribute back upstream (vs trying to cannibalize someone who could be your peer), and even reduces your engineering effort and the need to revalidate all the security primitives (and have 3rd parties do that for you just by their using it).

Disclaimer; I have nothing to do with HashiCorp, they've just done right by me, have been great to the community, and are always improving and learning from their mistakes. A nerve is struck when marketing tells people that they are using the wrong tool (without backing that up with data), and making comparisons to a protocol which has fallen to the wayside aside from limited use cases but otherwise is predominantly insecure.

Thank you for acknowledging the need for trust, self-hosting + auditability.

However, please stop trying to contrast yourself with these analogies. Owncloud and Nextcloud both have hosted OR on-prem versions

https://owncloud.com/pricing/

https://nextcloud.com/providers/

Understood, and yes my comment was harsh, perhaps a bit much so

However `Enterprise tools like HashiCorp Vault and AWS Parameter Store felt like we were stuck using FTP instead of Dropbox!` is in itself bashing other peoples' work, and misleading prospective users.

It's not alright to mislead people, and the trends over the years of new engineers without a ton of experience looking at a battle-hardened, vetted system with their one specific use case and no understanding of the endless numbers of refinements that resulted in the predominant solution that solves more problems and edge cases than just their partially understood use case, is... why we have shit like this coming out of Apple (for example)

https://lapcatsoftware.com/articles/macl.html

Despite being a millennial, I can't help but agree with this sentiment:

When I try to list the contents of the Documents folder in Terminal, I get a permissions dialog, because Millennials are killing Unix.

Understand _why_ things are done the way they are before you write them off as inferior and re-invent the wheel, otherwise you'll simply discover all the things you didn't understand previously, and create effectively the same solution, only poorly implemented and without all the vetting and refinement that went into what was already there before you came and "did it better".

I am not invalidating someone's right to privacy.

You are saying that not having the choice to choose what to share is acceptable though. Privacy isn't about having something to hide, it's about having the same rights you have with your day-to-day thoughts; you aren't forced to shout every single thought that pops into your mind, you are able to pick and choose what you would like to express and share. Privacy and encryption aim towards that goal.

with this setup, Vault will create a new database user based on the configuration you set (read-only for some services, for example), and will attach a time-to-live to those credentials; as long as the application is using them, it will renew the TTL. When an application is killed, or scaling happens, etc, and the application instance isn't using those specific credentials, Vault will clean up and remove the unused account cleanly

Can do all sorts of great things with this; for example TLS (ssl) certificate renewals, etc, as the certificate expiry IS the TTL; when a certificate needs to be renewed it can happen automatically and your application can receive any signal you choose (SIGHUP, for example)

Wait wait wait, and this is paid and hosted too? Bleh, nooooo thanks. I'm not sending private and secret key material to a bunch of ex-Uber employees (gross on that point alone), but nevermind to ones who looked at the existing market, didn't understand the tool-scape, and essentially decided to roll their own crypto...

It looks like this https://www.nomadproject.io/docs/integrations/vault-integrat...

It's incredibly simple, and a breeze to use.

``` job "vault" { group "demo" { task "task" { vault { policies = ["database"] } template { env = true data = <<EOF {{ with secret "database/creds/production" }} DB_USERNAME={{.Data.username}} DB_PASSWORD={{.Data.password}} {{ end }} EOF } } } } ```

edit: thanks HN formatting

I guess dynamic secrets are too "ftp" for Doppler, eh?

You lost the entire audience who have actually used Vault before when you claimed it was too complex for your team to understand.. Why would I trust a company staffed with a crew that can't even understand the tools they are trying to compete with

I think part of the reason people are chiming in on the distinction is that a controller is comparable to a mouse for a computer; a controller requires something else for any functionality, at which point you're comparing a general computing device that can do anything to a much more restricted special use device

your comment said "decks" though - the ddj1000 is _closer_ to decks, but it's still a controller.

decks, you're thinking (some examples):

cdj350 cdj400 cdj800 cdj850 cdj900 cdj1000 cdj2000 xdj1000 etc

this guy mixes

It's literally impossible, in case you haven't tried recently.

If you don't want to send them a government issued photo ID, you can make a new account that lasts 10 minutes and then is locked on you and holds any accounts linked to it hostage as you can't sign in.

Kinda absurd. You can't setup a one time email, and one time facebook if you really don't want your movement online all linked to a government issued ID.

Sure you're sort of an idiot to make those assumptions, but I'm sure you already came to this realization about yourself years ago.

Yeah, I thought the same thing too, in order to give the fake like/follow some artists require before making their music available to download; took 10 minutes, my account was banned for "suspicious activity" (meaning I didn't start posting pictures of myself like a pleb), and a government issued ID demanded of me. Fuck that

I agree; this is how I've understood the terms for as long as I've been aware of and used them.

The lack of light = black, and light which includes literally all colours = white.

When light is "blocked" from passing, black. When light is "allowed" to pass, white.

I look forward to seeing what other concepts can be mutated to make a point on unrelated topics.

Has someone taken over Tavis's blog? Two posts in a row now that seem like he either just doesn't understand some concepts, or is intentionally disseminating nonsense that is pushing people in the wrong direction on things that really do bring about benefits related to security.

Few reasons off the top of my head:

- why doesn't everybody already encrypt everything to begin with? there's often a disconnect between the benefit and the ease/overhead of doing so (it's hard enough to for people to care about using distinct and strong passwords, or 2fa; if the implementer isn't concerned with their users' security then often no one is) - people are lazy in general and security takes effort for a variety of reasons. how many users do you know who want to put in more than one password on every boot/resume from sleep/hybernation (which would be necessary, as using the same password would obviously be dumb, and using a keyfile beyond the first layers breaks the model for having those layers in the first place)?

- hindsight is easier to gain than foresight. people rarely predict the specific fuck up that seals their fate, and most don't think about operational security at a high level of competency, never mind in ways that survive 5+ years of advancements in technology, and against someone whose job it is to keep on trying (or more realistically just waiting for developments/discoveries made in security research).

- how many operating systems can you name that support multiple layers of full disk (or root partition) encryption with little to no effort? probably the closest would be encrypted GRUB with LUKS, with ecryptfs for encrypted home, maybe an encrypted loopback filesystem, and finally individually encrypted files; mobile is far worse too (ie. how would you approach implementing your own several layers of encryption on blackberry? that's what system was broken in this instance). aosp/android? good luck. macOS you'll find much more difficult to do any 3rd party FDE, and anything you do get working will break in miraculous ways - close-knit integration hell. iOS? HA - try convincing Apple to let you do a better job on anything system-wide, and while you're at it convince them to let other browser vendors do a better job there too, it would seriously improve iOS and be great for the web if Safari wasn't holding the whole industry back.

Overall, it's generally not the encryption itself that breaks; sure sometimes, but far less often than other channels that can be attacked. Cold boot attack for a device still powered but locked to pull encryption keys from memory is fun, but more often it's a weak/dictionary-based password or a 4 digit passcode that bottlenecks the security offered all the way down to 16 measly bits, or just attacking the joints where the encryption begins and ends. If you weld a metal frame on top of a bamboo frame, it'll be the bamboo that breaks, not the metal.

Also, the article doesn't even specify if the encryption was broken; the "new technology capabilities" could have been simply the purchase of some new hardware tooling or software to extract and dump the keys from the hardware devices securing them, or simply a court order was obtained to compel RIM to do so on their behalf.

Defence in depth - too often I hear "whelp, we had a tiny crack in one of our measures, so it's game over, why even try?".

Imagine the scenario where service A has read-only access to the authentication db/table, whereas service B (which could be maintained/operated by an entirely different person/team that leverages a more stringent code review process, or simply one performed by better eyes) has write access to that same db/table - the credential database could be leaked but due to a variety of measures in place further compromise through that specific avenue is mitigated.

One of the primary goals of "security" is to stop an attacker from accessing things or being able to perform actions that they "shouldn't" be able to access/perform. When dealing with humans it is incredibly difficult to decisively achieve that goal. It could be a zero day, a vulnerability in a code dependency, or otherwise some service dependency or other such software (say an internal analytics system with its own entirely separate models and storage of data) that leads to a breach - the bigger the team/company, the more people involved, the higher the chances that someone makes an inadvertent (or intentional) mistake somewhere.

I do not agree that a compromise of any form should be considered a reason to not attempt to build a secure system resilient to layers and layers of human failure.

Arch, finally a distro that is stable BECAUSE it's cutting edge.

You're running just about the latest of everything, and you pick and choose everything you want to run. It becomes easy to try every window manager and desktop environment, because they are all there (and up to date!).