6 ms·

How to take credit for someone else's work on GitHub

• kevincox 5y ago
  Their response is to add a PGP key. But AFAICT they don't do verification on PGP keys either. So you could do the same.
  • _jal 5y ago
    Really? GH Enterprise definitely verifies GPG.
    • globular-toast 5y ago
      How does it verify them? They could ask you to sign a message to prove that you control the private key, but I don't think public Github (or Gitlab) does this. They just assume you hold the private key to any pubkey you upload. Alternatively your private installation could have a centralised trust store of keys.
    • kevincox 5y ago
      It verifies the signature but I was able to just add a public key that I found online to my account.
      • devrand 5y ago
        Will Github verify a commit associated with a GH account via an unverified e-mail address? If so then it's probably fine since you would have to demonstrate ownership of an e-mail address that was contained in the signed payload, or you would have to be able to sign payloads yourself (i.e. you have the private key).
• striking 5y ago
  This is just a fact of how attribution works in Git. It's not GitHub's responsibility to figure out exactly who should be given credit for which commit, they're just a viewer on top of Git commits. Imagine you did some work at some workplace years ago, and you want credit for it. You don't have access to that email anymore, but you'd still like to have the credit and have it link to your account. That's the usecase.
  • baobabKoodaa 5y ago
    > It's not GitHub's responsibility to figure out exactly who should be given credit for which commit, they're just a viewer on top of Git commits. If it's not GitHub's responsibility, then why are they doing it? Nobody forces GitHub to attribute commits to GitHub user accounts. (And yes, you answer this "why" question in your next sentence, I'm just pointing out that your argument is nonsensical.)
    • striking 5y ago
      Because they're trying to help build a social graph insofar as it helps people do their work, without the aspect of actually taking responsibility for being a source of truth around it. Sure, I could claim an original Unix dev's work. But what does that actually do, besides raise questions I can't answer at interviews?
• deleted 5y ago
  [deleted]
• SilasX 5y ago
  I remember this earlier subthread where someone was criticizing GitHub for allowing this (even using Torvald as someone to impersonate!), and others offered some defenses (which were IMHO dubious): https://news.ycombinator.com/item?id=21025378 https://news.ycombinator.com/item?id=21025378 Also, semi-related, obligatory mention of my joke utility for stealing credit for someone else's work: https://github.com/silasx/git-upstage https://github.com/silasx/git-upstage Finally, I thought this phrasing was funny, like commits have a non-substantively transferable ownership, like an NFT (though FYI it's quoting an older discussion of the same problem): >Someone wrote about the whole situation on Medium in November 2021: "The 1st commit of git/git no longer belongs to Linus Torvalds".
• i_have_an_idea 5y ago
  • peeters 5y ago
    I think you're missing the point of what the author is asking. Showing the email address from the commit is one thing (and the author is fine with showing that). That's the limit to what git gives you. Associating that email address to a GitHub user profile which never verified ownership of that email address is a GitHub UX decision, having nothing to do with git. That's what the author is saying is a security flaw. That said, clearly users shouldn't be ascribing any level of certainty to commits that point to a GitHub profile even if the email address is verified, since AFAIK nothing is stopping the inverse attack, i.e. having someone else take credit for your work. Which is arguably more exploitable.
  • jokethrowaway 5y ago
    That's not the main complain, the issue is that GitHub is allowing users to claim emails even without verifying users are the owners of those emails.
    • i_have_an_idea 5y ago
      how are they claiming emails?
      • peeters 5y ago
        > The problem is that GitHub makes this association even for unverified email addresses. In this case of course it really was Linus who made the first commit, but all it took was someone to add Linus's email address to their GitHub profile - without any verification - and now GitHub displays this person as the author instead.
        • i_have_an_idea 5y ago
          I can also write on my own web site that my email address is linus@linuxfoundation.org. But I can't send or receive messages from it, so how exactly would I be claiming it? Does GitHub allow you to impersonate Linus via email? No, it does not.
• anandoza 5y ago
  Could someone also write bad code and commit it using someone else's email address in the commit message, thus making the commit link to the other person's Github profile? (Sort of the reverse problem -- "giving blame" instead of "taking credit")
  • skeaker 5y ago
    Now you're thinking like the author of git-blame-someone-else: https://github.com/jayphelps/git-blame-someone-else https://github.com/jayphelps/git-blame-someone-else
    • 22c 5y ago
      IIRC there was an infamous (at the time) user hostile commit made to a Google product (Android or Chrome perhaps) where the author was obfuscated to something like "Android Dev" instead of an actual individual.
      • jsmith45 5y ago
        Perhaps this commit?: https://android.googlesource.com/platform/packages/apps/GlobalSearch/+/592150ac00086400415afe936d96f04d3be3ba0c https://android.googlesource.com/platform/packages/apps/Glob... Discussed in https://news.ycombinator.com/item?id=17487441 https://news.ycombinator.com/item?id=17487441
  • TrianguloY 5y ago
    Yes, simply change the email and author before commit and should work. Note that git already provides a way to mark a commit with someone else authorship, but in that case you remain as the "original author" of the commit, usually shown as "X authored commit of Y". I sometimes use that when I need to push other coworkers code for whatever reason, or when you start a codebase from an old project files that weren't versioned (so that you are not the author of all the atrocities of the old code ;)
  • klabb3 5y ago
    Yes, but it isn't limited to non-verified emails, you can do it with verified emails as well. I assume it's already used to obscure deliberate security compromises in forks etc. There are many practical impersonation vectors. I assume Github is gonna have to require signed commits for profile links in the medium term future.
• TrianguloY 5y ago
  Why not add a small orange (!) icon next to the name for unverified emails, or a similar indicator? As a way of saying "this user claimed authorship, but we couldn't verify it". When you commit from the Github page itself, a similar green "verified" check is shown, but if you do it from command line and then push nothing is shown. So the infrastructure for special verifications messages is there, and perhaps could be used.
  • roblabla 5y ago
    It's possible to show the "verified" check when commiting from the command line, you just have to sign the commit with a PGP key, and associate said PGP key with your account on github.
    • TrianguloY 5y ago
      I supposed that, but wasn't sure. Thanks for the confirmation!
• j3s 5y ago
  how many email addresses can a person associate with their account? is there the potential for me to develop a bot that scrapes every "unclaimed" email address and claim them? seems like a very poor design choice.
  • guessmyname 5y ago
    As of today (Feb 28th, 2022) GitHub allows you to add up to twenty (20) unverified email addresses to your account. When you reach that limit, you will be presented with the following error message “Please verify one or more of your unverified emails before adding another.”
• FlacoJones 5y ago
  One thing to note: I believe this only works if the email is not already associated with a GH account.
• whateveracct 5y ago
  Sign your commits if you care about this! iirc, isn't signing with the same ssh key you push with a possibility?
  • MaxBarraclough 5y ago
    I believe you could do that yes, but I don't think it's recommended. My understanding is that git itself offers no real solutions to the questions of key-management, especially revocation and rotation, so you're essentially on your own for all of that. Revocation seems especially tricky as it seems directly at odds with git's model of immutable commits. I don't know if there's a robust solution out there.
• spyremeown 5y ago
  I remember when one of our contractors refused to do a rebase for like, a week, and just ignored any messages we sent him. I changed my e-mail on git to his, rebase, push, PR merged :) Nobody ever found out hahaha
• svnt 5y ago
  I scrolled through all the comments and didn’t see this answer. What better way to recruit famous people to your platform than to allow people to trivially claim their commits until and unless they join and claim them? It is most likely driven by customer acquisition — hence the response “working as expected!”
  • throwaway82931 5y ago
    Github has made multiple decisions which, whatever the rationale, damage trust in them as an identity authority and make it more difficult to believe that a Github account represents who it appears to. They also allow for accounts to be renamed and then for someone unrelated to register the abandoned name: https://www.theregister.com/2018/02/10/github_account_name_reuse/ https://www.theregister.com/2018/02/10/github_account_name_r...
• clutch89 5y ago
  Why does the email address hijacking only work/show up for the first commit?
  • mynameismon 5y ago
    It is not merely for the first commit, here, the first commits are used as a proof of concept since they are large repostories known to everyone. You can try it yourself, by changing your email to something like Linus' email in your git config, and then trying to commit code. GitHub will automatically show Linus' profile.
• uncomputation 5y ago
  GitHub’s response is pretty surprising. How can anyone think this is expected? Having to follow Git’s commit message emails makes sense and indeed anybody can use any email they want to make a commit. But then for GitHub to make the connection between (unverified) commit emails and (unverified) GitHub.com accounts is the issue for me. Since they can’t verify the commit email belongs to a GitHub account, why show that as though it were true?
  • jodrellblank 5y ago
    What happens if Linus Torvalds has a verified Github account, and I commit to my rudely named project on my local computer with his email address and then push to Github; do they then show the commit with his Github account because his Github email is verified?
    • leeoniya 5y ago
      > and I commit to my rudely named project on my local computer with his email address and how exactly would this be out of character for the real Linus Torvalds?
    • jreese 5y ago
      Yes, and there are a number of past stunts that include forking the Linux repo, pushing fake/misleading commits, and then showing how Github lets you see those commits in a context that implies they are part of the upstream Linux repo.
      • charcircuit 5y ago
        Github now shows a warning when people visit links like that
        • seba_dos1 5y ago
          Not on every relevant view though, so there are still new waves of pranks and surprised people.
• rockbruno 5y ago
  It seems that one proper solution could be: 1 - Don't associate the commit to an account if the email is unverified, obviously 2 - If someone tries to "forge" ownership by pushing a commit with an e-mail that doesn't belong to the GitHub account being used to push, a "unverified" warning should be added to the commit and manually claimed by the account owning said e-mail for its status to change.
  • detaro 5y ago
    but pushing commits with other authors is a really common thing in many git workflows.
  • MereInterest 5y ago
    That would break any workflow that has the slightest bit of decentralization, and would only work in a github-first workflow. Suppose two developers are working on a feature that requires two changes. Each developer works on a change in their own development branch. It wouldn't make sense to submit a PR for each change, because they depend on each other to be a complete feature. Therefore, they should merge the two dev branches together, then submit a pull request for that merged development branch to then be merged into the main branch. In your proposed scheme, this would then show up as an attempted forgery, rather than a perfectly normal workflow. The email field is for humans, who can lie, and shouldn't be used as authoritative by github.
    • nebulous1 5y ago
      > this would then show up as an attempted forgery, rather than a perfectly normal workflow. they said unverified, not marked as a forgery > The email field is for humans, who can lie, and shouldn't be used as authoritative by github. and your solution is just to have everything marked as unverified, including commits that I push using my credentials and contain an email that I've verified with github.
• nynyny7 5y ago
  I do see a point in it working like it does, though. I'm one of the lead developers on a free software project with over 20 years of history. Even though the project has used multiple version control systems (and hosting providers) over time, we have imported our entire project's history going back to the very first commit into git and GitHub. Not every contributor has kept their email address for over 20 years. Some don't have access to the old addresses they once used for commits. Still they want the commits to be associated with their current GitHub account; even if it's just for statistics and "bragging rights". If GitHub required email address verification, how would this be done? EDIT: To be clear: With "working like it does" I'm referring to the possibility to add unverified email addresses to your account and have commits attributed to you.
  • baobabKoodaa 5y ago
    > If GitHub required email address verification, how would this be done? You could just run a script which rewrites the email address in all the git commits, and force-push the revised version.
    • giancarlostoro 5y ago
      Does this redo all the commit hashes?
      • nynyny7 5y ago
        Yes, as it is rewriting history. And that would be a massively bad idea.
        • giancarlostoro 5y ago
          Thank you, wanted to know, if so, this should really be noted when suggesting these sort of things since it has unaccounted consequences especially when you consider most people use git but don't necessarily know how to use it beyond the basics.
      • progval 5y ago
• huhtenberg 5y ago
  Arpad, your site looks like this - https://i.imgur.com/jj9Uxbl.png https://i.imgur.com/jj9Uxbl.png Not just the linked page, the homepage too. All but illegible. That's in a recent Firefox on Windows. Just FYI.
  • fabianhjr 5y ago
    Weird, looks like this for me: https://imgur.com/a/6qL0bWa https://imgur.com/a/6qL0bWa Firefox 97.0.1 Linux version 5.16.11 (gcc 10.3.0, GNU Binutils 2.35.2)
  • mminer237 5y ago
    I'm on Firefox 97 on Windows 10, and it looks as intended for me.
  • arraypad 5y ago
    Thanks very much for letting me know, I'll look into that!
  • caslon 5y ago
    At some point, we need to start treating Windows like Internet Explorer or Safari. Things break on it all the time, completely unpredictably, and it doesn't support many useful features you'd expect to be used. We should really just tell Windows users to upgrade to a real operating system, rather than go out of our way to support it.
    • ______-_-______ 5y ago
      I love comparing these kinds of comments to articles like this: https://sporks.space/2022/02/27/win32-is-the-stable-linux-userland-abi-and-the-consequences/ https://sporks.space/2022/02/27/win32-is-the-stable-linux-us... You really think businesses like Repography should just ignore the OS with 80% marketshare?
• deleted 5y ago
  [deleted]
• gorkish 5y ago
  I'm extremely surprised as well. This seems like a obvious vector for an impersonation attack. A malicious user could do this, then perhaps they would have more success submitting a malicious change to "correct a flaw in their previous commit" At the very least, repo owners should have some better control over how attributions display when the user is not a project member or the email used is not verified to an existing user.
• leonardinius 5y ago
  Dated back to at least 2015 https://news.ycombinator.com/item?id=10005577 https://news.ycombinator.com/item?id=10005577 It’s old news.
• a-dub 5y ago
  so this is obviously an ad for this repography thing, which looks pretty cool. so.. does it do anything interesting with stuff like git blame -CCC which shows the genealogy of copypasta across time within a repo?
• lowercased 5y ago
  I thought this might be something different. Have seen this happen multiple times over the years - even once just last week. Colleague files an issue with a PR. Project owners close it, say 'no, not a bug', then... commits the same thing themselves as "fixed!". Saw this years before in cvs/svn, and... at least in the GH world there's some evidence of the original PR author having done the work in the first place (vs being invisibly cut out).
  • jamjamjamjamjam 5y ago
    The owner of huey does this. He closes PRs and submits the code himself
    • elderlydoofus 5y ago
      I had this happen on a small PR I submitted within the past year. I didn’t think anything of it at the time, but your comment led me to glancing through the past PRs and it’s comical how many are closed with a “thanks, I’ve committed an equivalent patch” comment. One the one hand, it’s his repo and he’s free to do whatever he wants. I actually admire how ruthless the maintainer is on closing issues, must be great for staving off OSS burnout. On the other hand, I don’t love how antagonistic it is to outside contributors. Litestream[0] is an example of open source-closed contributions, but at least it’s upfront about that in the README. (And the policy has actually changed to open for bug fixes.) I would open an issue/PR on Huey suggesting adding a similar disclaimer, but it’d probably be closed, ha. [0] https://github.com/benbjohnson/litestream#contribution-policy https://github.com/benbjohnson/litestream#contribution-polic...
      • not2b 5y ago
        In many cases this is the right thing for a maintainer to do: a contributor produces a PR and a proposed patch, but often that patch doesn't solve the whole problem, or clashes with the coding style, or isn't very efficient, so the maintainer does their own fix, because that is faster than getting the contributor to produce a modified version.
• denysvitali 5y ago
  I noticed that arraypad is really trying to push his repography project. Whilst this is not a bad thing, it seems like he is using the blog posts as an excuse to push more his project. I don't mind that much, but I think I've seen these posts hitting the front page quite a lot already - it's a good strategy but it could be maybe against the guidelines: > Please don't use HN primarily for promotion. It's ok to post your own stuff occasionally, but the primary use of the site should be for curiosity.
  • blunte 5y ago
    I didn't look at the previous posts you mention, but TFA is what I would consider of interest and curiosity. I didn't find it at all to be self promotion. You have to read to the bottom of the post before you are told what repography is selling.
  • adewinter 5y ago
    A grand total of 7 submissions to blog posts over the course of a month is probably fine.
  • tln 5y ago
    Personally I think this submission and the other one[1] that probably made it to the front page are excellent :) [1] https://repography.com/blog/go-first-commit https://repography.com/blog/go-first-commit
• moritzwarhier 5y ago
  I'm not entirely sold on the explanation "This is just how git commit (messages) work". GitHub could easily limit linking the GitHub profile to profiles whose e-mail address has been verified (by usual means, no GPG required). They could show statistics and attribution limited to the data available in the commit messages (e.g. accumulated statistics by e-mail address) for contributors without a GitHub profile. Am I missing something here? (Edit: just read the other comments addressing the use cases)
• zestyping 5y ago
  An obvious and feasible improvement is to least make it clear in the UI which addresses are verified or unverified.
• myroon5 5y ago
  I have used emails in the past I can no longer verify, so I see a use case for linking unverified emails to profiles if there's only one profile claiming the email address However, if another profile verified that email address, it definitely shouldn't link to another profile that hasn't verified
  • bluGill 5y ago
    That isn't fair either though. I can see the ISP I quit using 15 years ago letting someone else have my old email address, but now they can claim to be me. I don't know how to handle this situation. It is somewhat easy to verify that a commit today comes from an email address I control now. However if I claim an unverified commit from years back is it really me just because I now control that email?
    • totony 5y ago
      What does it matter if someone can claim your commits? Doesn't seem important imo.
      • hyperhopper 5y ago
        Since [by default] you own the IP for code you commit, this is effectively claiming to steal intellectual property. Also professional credit and fame, which can directly relate to employment opportunities.
        • totony 5y ago
          AFAICT they can only claim it because you haven't claimed it so >which can directly relate to employment opportunities. doesn't seem right. Agreed on the copyright part of the equation, but I don't think many people take the commit author on GitHub as the copyright owner.
        • krageon 5y ago
          > intellectual property This seems to me to be the least important aspect of whatever is happening. > can directly relate to employment opportunities Given how free we are in choosing work, it seems to me you could just go work for a workplace that doesn't trawl through your charity history to figure out you're worthy enough. That's a matter of self-respect, which you should absolutely have.
• anfractuosity 5y ago
  What happens if multiple github users add the same unverified email address for a particular commit in a repo to their accounts, how does it know which github username to pick to display next to the commit?
  • guessmyname 5y ago
    An email address can only be associated to a single GitHub account. If “Alice” adds alice@example.test to their account, GitHub will check if the email is not associated to an existing account, and then proceed to handle the request. Then, when “Bob” tries to add the same email to their account, GitHub prints the following error message “ Error adding alice@example.test: email is already in use.” In your example, GitHub will display the username of the first user to add the (unverified) email to their account.
• anglinb 5y ago
  I worked on the security team at GitHub, this was a long standing part of how git works. GitHub allows users to verify commits via GPG signatures to prove that they committed something but it doesn't work for proving a negative, that you did not commit something. We got so many of these submissions which are clearly called out in the rules/scope, usually the people who don't read the rules don't find anything useful. ¯\_(ツ)_/¯
  • vgel 5y ago
    Obviously anyone can attach any email to any commit, but why does the frontend UI work like this: gh_profile = get_profile_with_email(commit_email) and not this? gh_profile = get_profile_with_email(commit_email) if not gh_profile.has_verified_email_ownership(commit_email): return null
• quickthrower2 5y ago
  Because Git/Github is source control tool not a forensic tool.
  • MaxBarraclough 5y ago
    This implies that assuring a commit's provenance is beyond the scope of git, which is wrong. Git supports cryptographic signing of commits for this purpose.
    • quickthrower2 5y ago
      It implies such signing is nit used all the time
• nyellin 5y ago
  Repography looks very cool, but why does it need permission to "act on my behalf"? Is it possible to use without connecting my user at all?
• kazinator 5y ago
  In spite of GitHub's claims that nothing wrong, something is wrong and fixable. GitHub should be showing the identity pulled from the e-mail address, and not replacing it with the name of an associated GitHub account. Just like it does when there is no associated GH account. A reasonable compromise would be to show that name, but turn it into a link to the account if there is one. Then only someone curious clicking on "Linus Torvalds" would see: hey, how come this leads to some VanTudor account?
  • jeroenhd 5y ago
    That wouldn't work, for example, when you're pushing commits someone else did in another repository. Git is decentralized, so you end up pushing a lot of code that you didn't commit if you use it the way it was intended. The solution, in my opinion, is to show a great big warning or error icon next to the name of every unverified commit, and to every unverified push as well. Developers and version control managers can easily prevent this from happening but few see a reason to sign their commits, and perhaps with a UI change discrediting commits this can change in the future. Setting up signed commits takes five minutes, less if you already have a PGP or S/MIME certificate. The trick the article shows is a neat trick that will confuse people that don't have any knowledge of how Git works, but the dangers of unconfirmed commits exist go beyond that. A malicious actor could easily inject a backdoor by injecting fake commits impersonating a trusted project member and very few people would be the wiser, unless they actually check the commit manually. Enterprise/Pro versions of version control software (such as Gitlab) have this feature, but bots exist for free versions as well. You could change CI/CD pipelines to fail if the branch contains unverified commits to hack the functionality into the free version of such systems.
    • allset_ 5y ago
      GitHub already has this, called Verified Mode [1]. It has to be opted into rather than out of though. [1] https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits https://docs.github.com/en/authentication/managing-commit-si...
    • 5y ago
• guptarohit 5y ago
  for these reasons I have started using PGP signing for commits and releases I make
• nfoz 5y ago
  Veering off topic but I absolutely hate that git requires you to have an "email address" (which cannot be empty and iirc must satisfy some regex criteria for a valid-looking address). A particular choice of user identifier or communication medium should not be hardcoded into the totally unrelated concern of source-control, IMO. Anonymous and non-email accounts should be first-class things. Instead of email maybe you'd want to have your public-key or something.
  • Bayart 5y ago
    AFAIK git was made with an email workflow in mind. Git's the byproduct on the Linux kernel project, for better or worse. GitHub provide a fake email address that's tied to your GH account for commit stats, which is an appreciated utility.
  • marwis 5y ago
    Nothing is stopping you from using anonymous@localhost or YOUR_KEY_ID@publickey
• aledalgrande 5y ago
  This is trackable, but I had my PR closed and my contributions redressed as another PR a week later by the members of a few different prominent opensource projects, without any communication on their part. And I only realized by chance.
• gurjeet 5y ago
  I think if the project included a mailmap file [1], supported by Git, and if Github honored it, this may not be a problem. [1]: http://git-scm.com/docs/gitmailmap http://git-scm.com/docs/gitmailmap
• pornel 5y ago
  I knew about the ability to push commits as someone else, but GitHub allowing taking ownership of other people's commits in their own repos, using an unverified e-mail address seems like a whole another level of insecurity here. Even though git -> email link is weak for reasons beyond GitHub's control, I expected email -> github account link to be reliable, since that is entirely under GitHub's control. I think GitHub is needlessly making a bad situation even worse here.
• trombonechamp 5y ago
  Or you can just do this: https://github.com/bhargavchippada/forceatlas2/commit/7438e2e48347a70d6ebd0bafcca22aea86629a79 https://github.com/bhargavchippada/forceatlas2/commit/7438e2...
  • zeusk 5y ago
    yikes, and by the looks of it seems like a "refactor" at best
  • sky_rw 5y ago
    As I understand it, this is not permitted under the GNU General Public License v3.0. Is that correct? I would think that certain licenses do permit this (MIT possibly?). Could anybody with knowledge chime in?
    • manwe150 5y ago
      MIT prohibits this. You can use the code and remix it or add your own copyrighted code, but pretty much the only thing you can’t do is remove the original copyright text.
    • pabs3 5y ago
      I assume copyright law prohibits this too.
      • globular-toast 5y ago
        Copyright law doesn't care about copyright notices. They are informational and not necessary or sufficient to enforce copyright.
  • sdesol 5y ago
    This appears to be the repo that the copyright originated from https://github.com/mwshinn/forceatlas2-python https://github.com/mwshinn/forceatlas2-python bhargavchippa also contributed to this repo, so this doesn't seem like one of those random "fork and lie" sort of thing. Without the necessary context, we can't assume much. It could well be that mwshinn was in the wrong or there was an "okay" from mwshinn for bhargavchippa to make those changes.
• ILMostro7 5y ago
  Is it at all relevant that github is not a source of authority for anything, unless the project itself chooses it (and maintainers/owners designate it) as the platform of choice for source control?
• dogweather 5y ago
  Just ask Sushi Swap.
• whiddershins 5y ago
  Whether working as expected or not, just fix the Linus thing, that is an embarrassment and a surreal one at that.
• globular-toast 5y ago
  This reminds me very much of a "hack" I performed in a workplace that used Outlook/Exchange as its primary email system. I simply sent an email (to a few, trusted people) with the "from" field set to the CEO's name/address. In their inbox it looked completely legit. Outlook even put the CEO's avatar next to it and everything. They were genuinely shocked. Even after I explain that the "from" field is just like me writing "love from Mum" at the bottom of a letter I think they still couldn't believe it. There is a problem with people assuming that all data they find is authoritative. People don't question whether they can trust data often enough. Another problem is when you make things look nice enough, they look trustworthy. This is a well known confidence trick, of course. My PhD supervisor objected to me typesetting my work in LaTeX before it had been checked because he said once it's typeset it looks correct, but might still be complete rubbish. Unfortunately this all boils down to web-of-trust, as usual. We've had the solution for decades now, but we've collectively agreed that it's more trouble than it's worth. So these kinds of problems will keep popping up again and again.