GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
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.