Hacker Newsnew | past | comments | ask | show | jobs | submit | Gargyle's commentslogin

Complains about tracking, uses google assets.


What an egregious mislabeling.

Data -> Chats and actual Identity

Metadata -> Who with whom and when from where,...

They construe payment info, PII and similar except chat contents as metadata and say metadata of metadata was that which is normally called metadata. And that it was safe to share despite this obviously being not true.

Everyone remembers https://www.nybooks.com/daily/2014/05/10/we-kill-people-base...

?

How does one understand the authors motivation?


> Data -> Chats and actual Identity

> Metadata -> Who with whom and when from where,...

Metadata of the metadata: "aggregated datasets showing how many users a platform has, where accounts are created and when, how information travels, which types of messages and format-types are fastest to spread, which messages are commonly reported, and how (and when) users are booted off."

That information should be safe to share if aggregated over all users.


One man’s metadata is another’s data.


Are there resources on the impact of Keybase being bought by Zoom? Zoom is out of question too because they discourage e2e and darkpattern you into installing their software despite browser compatibility and because they darkpattern you into giving cam/mic access just to listen to a broadcast-only session even if unnecessary. They place their own controlled device toggles as source of truth instead of those by the browser UI and fail in weird ways if you toggle in-browser. (Same for almost all other similar software as well)

I tossed them without a second thought after they annoyed me with Stellar. Nobody uses Stellar if they dont have a hidden incentive. It always had a huge forced marketing vibe.

Is there some sucessor to keybase?

(Motivation disclaimer: I want to dump on Keybase because in the end, even with flawless crypto at first, those organizations always erode the good things down to centralized with platform control again.)


> Is there some sucessor to keybase?

Depends on the use case. E.g. for raw identity proofs https://keyoxide.org works well but it's not as straightforward to use as Keybase.


Cryptographic Trust /= Trust in persons motives.

I guess we need better words.


SSH tooling does not make that any better tbh.

Things are being worked on.

Watch Sequoia.

Maybe some things regarding UX on my radar will surface in a range of <2 years.


Maybe this needs more precise wording. Like ingress/signature key but more compressed instead of public key. Or peer key. Any nice ideas?


That's a good point. The wording makes sense from a cryptographic point of view, but it doesn't really convey the full meaning outside of that context.


Its actually the same thing. A shared identifier. Of course email is another thing to separate for separate identities. But it is way more widely known that email adresses are used ad an unique identifier.


That’s my point though. If you’re concerned about privacy enough that even a throwaway SSH public key is sensitive then GitHub (and even any public git repository) is going to be a bad idea because they’re going to be leaking far more identifiable data than just your SSH public key.

If you agree that said platforms leak lots of other identifiable data (which you seam to) then thus it is a fair statement to say GitHub hiding public keys do little to enhance your privacy. And thus one can reasonably conclude that privacy argument doesn’t really hold with regards to SSH keys.

I’m happy to agree that it’s bad UX and probably should be advertised better so people are aware they should follow the (in my opinion best practice) of using a unique SSH key for GitHub.


You might have gotten me having this too narrow to be broadly useful. Because we were already arguing about a detail and I concentrate just on this detail, not a general github privacy overview.

The whole intention was to raise attention to a less often mentioned part of the information github exposes about accounts.


That happens as part of the ssh handshake. And is the basis of this whole scheme. No idea if there is tooling to.do.that for arbitrary messages.


Attaching this to cryptoassets increases your operational (more mental overhead, doesnt work with simple keybearer devices, you assume people to be lazy and bad at key management) and technical (irrevocable ethereum-bugs that can only be mitigated by chain splits) complexity.

Albeit for long-term public signatures I see the benefit in spreading the sig and revocation information from the classical tools in to as many hard to modify places as possible. Popular global databases like Ethereum and similar are good condidates for that.

And of course have the verification scheme expose inconsistencies between different key-sources and tag them with their respective power structure categories. (Lime Government, Cryptocurrency-Devs, HugeCodeHostingPlatform, CompanyBehindHugeCodeHostingPlatform, etc...)


An Ethereum address is just a public key (which, as the owner, you also have the private key to). You can make one, and sign messages with it, without touching the blockchain or sending any assets to it. So added complexity is -necessary- only to the extent you wish to involve those additional ways you can interact with the blockchain (that you can't using GPG or SSH keys). I'm saying this in principle of course, granting the current lack of convenient utilities/CLIs for operating this way.

I would speculate that there are probably already more people who practice decent opsec for their Ethereum keys than for GPG & SSH keys. Soon it won't be close!


Then this is bad advice in general because its specific to a low trust expectation. Would be sensible to note that in your comment.


it's not advice at all. they are just saying you can do it.


The parents comment style is inherently advice.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: