HN Gopher Feed (2017-09-18) - page 1 of 10 ___________________________________________________________________
Introducing Keybase Teams
193 points by jashkenas
https://keybase.io/blog/introducing-keybase-teams___________________________________________________________________
Walkman - 2 hours ago
I didn't see that coming; Keybase want to be Slack 2 :D
malgorithms - 5 hours ago
Blog author here. In the interest of keeping the post more of a
summary, we left the cryptographic details to our docs. Here's a
link to that: https://keybase.io/docs/teams/index . We're happy to
answer questions here.This really is an exciting product for us.
Once you can define a team, cryptographically, without server
trust, a lot of other things follow. We'll be launching some of
those things in the coming weeks.Also left out from the blog post:
teams (and chats) can be controlled through a local API, so pretty
much everything in Keybase can run in the form of a bot, also
without trusting Keybase servers. Cheers to crypto!
artursapek - 1 hours ago
Are you worried someone will dictionary-attack this feature and
just claim all of the good names?
insomniacity - 1 hours ago
When will you add file support to the mobile clients? We're
absolutely dying for it over here!
coenhyde - 34 minutes ago
Is it possible to encrypt with teams? eg `keybase encrypt -m "my
message" {{insert team name here}}`
LeoPanthera - 4 hours ago
If you delete a team, can a new one be created with the same
name?Edit: Additionally, are team names private? Can they be
discovered without guessing them? If you guess one, can you prove
it exists?
malgorithms - 4 hours ago
nope! We feel pretty strongly this is the right answer.
malgorithms - 3 hours ago
Answer to your edit: team names are not private, as their
hashes can be found in our merkle tree, which anyone is free
to mirror or lookup. So if you name your team `foobar`
someone would be able to hash foobar and look it up, and yes,
prove it exists. This is a feature, not a bug :-)But if you
picked a team name with very high entropy, then I guess that
would be semi-private in that it would be undiscoverable by
brute force.
tehno - 2 hours ago
Same goes for sub-team name? I.e. don't put private project
names, future release date related things etc in there?
xnxn - 2 hours ago
"The very existence of subteams are hidden from all who
aren't members of the subteam. Thus, if you wanted to
create the team `lets_fire_bob.just_kidding_fire_bruce`,
then Bruce would have no way of knowing his number is
up."(from https://keybase.io/docs/teams/design)
thecoffman - 4 hours ago
Does the presence of files in the teams feature mean that kbfs
will be rolling out to the iOS app? Its been "coming soon" for
awhile now and has always been the more compelling feature to me
than chat :) Either way, congrats on the release, this looks
really awesome!
malgorithms - 3 hours ago
It'll come after some improvements to team management and chat.
But it isn't that much work, technically. KBFS is already
running on your phone and understanding the filesystem... (your
phone helps rekey data when needed.) It's just about building
an interface around it. Which is no small task. It needs to be
good. Hopefully soon.
gr2020 - 2 hours ago
I'm sure you're thinking of this - but integration with the
iOS 11 Files app would be awesome!
CodeMichael - 1 hours ago
+1 -- I would really like files to be working at all, but
integration with iOS11 files feature would be amazing (also
would love to see iPad working)
amingilani - 2 hours ago
@malgorithms is there any support to change usernames? Before
teams, I had a company PGP key under the company name, but with
this launch I can't create a team with the defacto company name
since it's already in use.
amatix - 3 hours ago
OT, but any update on exploding messages in Keybase chat? (or did
I miss it?)
malgorithms - 3 hours ago
we pushed it behind teams, but we'll do it soon. 2 things we
want to work on shortly:(1) switching to short-term exploding
message mode (what you would expect from OTR), so your messages
can be read and then disappear. And devices don't cache them.
This has inconveniences, especially for team chat, but it's
what you might want in certain sensitive situations or certain
DM's.(2) a message auto-deletion policy for the team. This is
different, and it's been requested by some testers.
ineptech - 3 hours ago
Can the team creator give up admin rights on the team without
resetting her user? I want to create a team for my employer so
we can try it out, but I'm not the person they would want to be
the admin if/when they adopt keybase.
malgorithms - 3 hours ago
Yes, you can be the initial owner and then add other people as
owners (or admins). From there you could downgrade yourself to
a regular user - or if they're owners, they could downgrade
you.They could also kick you out. I've done this a few times
today. We reserved a number of team names for known tech
companies, and when they've asked, I've created the team
myself, added a couple of their managers as `owner`s, and then
they've booted me.You can think of the team's sigchain as just
a string of signed announcements. You can sign someone else in
as owner.
zokier - 2 hours ago
> We reserved a number of team names for known tech
companiesI think this demonstrates the problem of creating
completely new namespace from scratch. One way to solve that
would be to couple the team namespace to DNS namespace; to
claim a team name you'd need to demonstrate the control of
corresponding DNS name, same way as you do for DV
certificates. Of course I can understand that you'd want to
support teams for organizations/groups that might not have
their own domains, but you could support such cases by
creating a "pseudo-TLD" (or just straight up buy your own
TLD), for example .keybase.
phinnaeus - 1 hours ago
But control over DNS can change, right? If you sold or
forfeited your domain name, how with this separate
authority know to revoke your access to the team name as
well? Should they even do that?
dexterdog - 1 hours ago
If I stay in a team chat for a long time including files and all of
that do all of my devices keep a copy of everything said and worse
every file posted?
fiatjaf - 1 hours ago
Where and when do you get paid?
tanderson92 - 1 hours ago
Interesting, good to see that they've thought this one out a bit
(many other unis too):% keybase team create caltechERROR this name
has been reserved by Keybase staff, perhaps for your team. Reach
out to (email redacted) for more info. (code 2650)
hamandcheese - 3 hours ago
I haven't had a chance to try the app yet, but I'm very curious:
how will searching work? That's the only real thing I can imagine
would prevent this from replacing slack.
koolba - 3 hours ago
Very cool. Regarding team naming, is there anything preventing one
from registering "google" or "google.com" as a team name?
frenchie4111 - 1 hours ago
In another post the blog author mentioned that he reserved team
names for a bunch of well-known tech companies.
fiatjaf - 31 minutes ago
I don't know why this is being presented and commented about as a
bad thing, but globally unique names for teams, just like for
users, is very good.
wilg - 4 hours ago
I'm getting this error upon trying to create a team:> can't create
a new team without having provisioned a per-user keyAccording to
the docs (https://keybase.io/docs/teams/puk) it should have
automatically been created for me, though? Not sure if relevant but
I did not use the auto-updater to update Keybase for macOS (if
there is one), I just downloaded the latest DMG.
tanderson92 - 1 hours ago
I have the same error. And what's strange is I believe I do have
a per-user key on this device. At least I think I do, based on
the output of `keybase device list`
maxtaco - 3 hours ago
In case anyone's curious, all Keybase users are now getting "per
user keys" (PUKs). It's a key whose secret key is encrypted for
each of your devices, and whose public key is advertised publicly
in your sigchain. New users get a PUK right away, and older
users run a background thread to make one. wilg's thread missed a
window and would have rerun in 50 minutes, but he solved the
problem by starting up a different device.In turn, all team
crypto operations happen for PUKs (and not device keys) so it's
necessary to have a PUK before you can use teams. These details
are mainly hidden from users, except for bugs (as above, but
we'll fix it soon). This is a change from previous designs, but
the advantage is that when a user adds a new device, she'll get
instant access to all teams, when the PUK's secret key is
encrypted for the new device. Whenever a user deletes a device,
there's a rekey cascade --- the user's PUK is rotated, and so are
all teams the user is a member of.More info here:
https://keybase.io/docs/teams/puk
Gaelan - 3 hours ago
How does this interact with device compromise?
azag0 - 3 hours ago
From the link: "On device revoke, the revoking device makes a
new master key, encrypts for the private key for all
remaining devices, and writes the new master key to the
sigchain along with the statement revoking the old device."
maxtaco - 2 hours ago
Exactly. Sorry for the doc bug there. s/master key/PUK/g,
now fixed on the site. An earlier internal name for PUKs
was "master keys" but we've since changed.
bruce_one - 21 minutes ago
Unrelated, but any interest in making the Android app available via
a non-Play-Store medium?
ScottEvtuch - 5 hours ago
I'm curious about the decision to make team names globally unique
and unchangeable. It obviously has some trust benefits in that you
can't spoof a team if you know the name, but shouldn't the proof of
legitimacy be in the membership and signature chain, not the
name?If Keybase popularity grows, then any sufficiently large
company will probably have to use "CompanyName-Corp" or something
equally vague as their team name would be taken by squatters. A
malicious user could invite someone to "CompanyName-Corporate" and
most users probably wouldn't even notice.
gregmac - 4 hours ago
Requiring the team name to be a domain name (validating that they
own said domain name) seems like it would be a reasonable
solution. Domains are already globally unique, already tied to
organization identity, and already closely related to anything
keys will be used for (software, e-mail, etc).Someone could still
spoof "companyname-corp.com" but then it's at least obvious in
the same way spoofed URLs already (usually) are.
james_pm - 3 hours ago
Domain names as identity is something I would love to see
happen, mostly because I have a vested interesting in selling
millions of people those domain names via Hover.comKeybase does
a nice job aggregating those various identities, be it a domain
name, Twitter handle, HackerNews ID. It's probably a better
solution to help people/businesses establish an interconnected
series of online identities that are provably the same
entity.ps. Thanks to Chris for reserving some of the more
common team names including hover and making sure we could get
our hands on it.
LeoPanthera - 4 hours ago
What happens if you forget to renew your domain name, or
someone steals it by the trademark rules? Would that person
then gain access to your encrypted chat?
WorldMaker - 3 hours ago
If it's just a pointer to a merkle root for the admin chain
then they don't get access to the encrypted chat, they'd
still have to request access from an existing user.You could
simulate that today by say creating a weird named team (say
random GUID), adding a text file like .well-known/keybase-
team.txt on the domain with that team name, and then
encouraging people to sign up via something like: keybase
request-access `http GET http://example.com/.well-known
/keybase-team.txt`
proactivesvcs - 4 hours ago
What if neither Alice nor Bob have a domain name? What happens
if the domain name is dropped, transferred to a third party,
suffers a dispute etc?
zokier - 1 hours ago
Keybase could just offer free subdomains from a domain owned
by Keybase for people who don't have their own domains.
malgorithms - 4 hours ago
There are so many conveniences around a global team name. Any
time we played through the mental exercise of ambiguous names, it
led us back to the deep pains of reading out loud security codes
or fingerprints, or relying on some kind of hard-to-use web of
trust around trusting people and then their vouching for teams.
(note people, too, have unique names.)With our testers, I've
already had so many conversations about team names. If it's an
in-person conversation it's validated entirely without looking
anything up. If it's digital over an alternative medium - then
the sharer doesn't have to go look up their team's identifier in
order to talk about it. Everything is easier.Also, I'm not that
cynical by nature, but I've had a lot of conversations with
people about security since we started Keybase. People don't
check codes. From encrypted chats to SSH server fingerprints
(ugg!) -- people don't check them. If a team name can be
equivalent to one, but the cost is that the space is limited,
it's worth it.I guess in summary: why is a name better than a
fingerprint? It can be memorized without effort. It can be
visually or verbally reviewed without effort. And it often has
meaning.
another-dave - 2 hours ago
One option could have been to use top-level domains for a team
(e.g. add a TXT record to prove ownership of 'example.com' and
then you can create that the 'example.com' team).Out of
interest, is there a reason you didn't go for that? Would be
easy to memorise and validate while also ensuring uniqueness.
Feels like it could also play in quite nicely with letting
people on-board ? e.g. you could have a feature that anyone
with an email address in my domain is allowed to join the main
team without needing admin approval.That said, this sounds
great ? can't wait to try it out :)
azag0 - 1 hours ago
Potentially, they could still roll this out, because a dot,
".", is currently not an allowed character in a team name.
rcthompson - 2 hours ago
> [A name] can be visually or verbally reviewed without
effort.Have you considered the possibility of typo-squatting,
look-alike Unicode characters, and other such tricks (basically
all the same tricks people use for domain names)?
xwvvvvwx - 2 hours ago
So I think Keybase is an amazing product, and this seems great as
well, but I get a bit stressed that everything is free.I would
happily pay for kbfs alone and I would hate to see them go under
because they run out of money.
adammenges - 57 minutes ago
Awesome work, thanks guys!
moontear - 3 hours ago
"Error this name has been reserved by keybase staff, contact
chris@..."Tried multiple generic names as well as some random
companies. Might I ask what you are basing your "blacklist" on?
e12e - 2 hours ago
> But Keybase teamwork is end-to-end encrypted, which means you
don't have to worry about server hacks. Alternatively, you can lie
awake at night...fearing a breach of your company's messaging
history. What if your team's history got stolen from Slack and
leaked or published? The legal and emotional nightmare.I think it's
great that this is an e2e solution, and obviously the path for an
attacker from total compromise of keybase, to total compromise of
user data is one step removed - it needs to go via pushing a
backdoored keybase client (or, ahem, a secret entity needs to force
that to happen).But either way, in terms of a targeted attack for a
company's data - surely the clients (phones, workstations) are the
weak point? In other words, I think the paragraph oversells the
benefit of e2e a little bit?This isn't really keybases' fault -
consumer computing is pathetically insecure and hard to secure
(with the possible exception of iOS devices). That's just how
things are right now.
nickpsecurity - 19 minutes ago
" it needs to go via pushing a backdoored keybase client (or,
ahem, a secret entity needs to force that to happen)."Or just one
or more packets directed at the client if it has some kind of
listener open with a vulnerability. If nothing else, most
security-focused apps don't do covert channel analyses. If this
one doesn't, its secrets might be intercepted through storage or
timing channels via another compromised app (even unprivileged)
on the computer. Mitigating that usually has a performance hit
and/or takes a language whose operations map pretty well to
hardware where developers can estimate timing well.So, they've
removed one step. That's good. Opponents don't have to go
straight to subversion from there, though. There's a few more
possibilities.
lettergram - 1 hours ago
I like the service keybase provides, but I don't think it has any
chance of taking off with the general public.18 months or so ago I
wrote an app called AnyCrypt, utilizing Keybase under the hood:
http://lettergram.github.io/AnyCrypt/The idea was to make it easier
for my friends and I to send encrypted messages over any medium.
Facebook Messanger, Slack, G chat / hangouts, etc. Facebook
couldn't look into our messages, and everything was pretty easy. It
took two clicks, which was a pain.. but because we were security
conscious we could power through.On the other hand, most people I
work with, my family, other friends, etc. don't have the patience
for that. It needs to be no clicks to at max one click. The current
route keybase is continuing to take is a command line interface
with multiple commands necessary.The CLI is simply not going to
catch on for the normal user. The experienced users just use their
own PGP keys and manage it.As for the new interface, it does look
nice. However, the fact it needs to be a unique chat name is kind
of a pain. Why not just sign a unique identifier to the chat, then
rename locally? Similar to the way Signal does it? Also, what
happens if you recent your PGP key?
fiatjaf - 32 minutes ago
Are you serious? Seriously? REALLY?I don't believe this comment.
ktta - 30 minutes ago
Your idea is really good.Have you thought about having the
extension read all of the page, look for PGP encrypted message
and automatically decrypt the message? It wouldn't be compute
intensive if you optimized for a specific website. Also getting
the submitted message and encrypting on the fly?Also, having to
thought about how this could work for phones?
alain_gilbert - 1 hours ago
I never looked at facebook network activity.But I'm wondering if
they are not actually logging your keystrokes (or google
analytics).Otherwise, AnyCrypt looks awesome.
libertymcateer - 14 minutes ago
How did you deal with text injection into react forms on
facebook?Whenever I interact with text in a form field on
facebook via a browser extension, it is not picked up by react,
and the original text is what is picked up on submission. I've
banged my head into this problem repeatedly. Is there an easy fix
or is this something much more subtle?
skybrian - 1 hours ago
This looks like the start of a viable social network with very
strong security.At one point I would have thought that's great, but
now I find it vaguely alarming. Maybe this is overly cynical, but I
wonder what happens if it really starts to take off (say, growing
towards Twitter scale). At what point does it become yet another
social network that's degrading into a cesspool? And how do you get
out of that state when everything is cryptographically locked
down?The lesson of Bitcoin seems to be that cryptographically
irreversible actions combined with valuable digital assets (whether
coins or, say, celebrity accounts) have a tendency to attract
scammers and hackers, so you better be certain that your client
machines can't be broken into and that you're immune to social
engineering. And who is that certain?I'll probably try it out, but
I think undo buttons are really important. I'd be more comfortable
if there were some trusted people who can roll back mistakes and
fraud after they've been discovered and proven. (But, then again,
how do we know they can be trusted?)I guess this is all just FUD,
but, hey, I'm feeling it.