This was my experience with matrix.org, mostly pedos and far right extremists or other weird anti social characters . Turned me off from these kinds of platforms big time.
if you’re talking about the matrix.org homeserver’s room directory - these rooms are strictly against our terms of use (section 6 of https://matrix.org/legal/terms-and-conditions/) and we shut them down, and these days have even frozen the roomdir to stop them appearing.
if you’re talking about the wider network - yes, there’s a subset of abusive users… just like on the web, or the internet, or email, etc. Unfortunately there’s nothing we can do about; it comes with the territory of being an open network where anyone can participate.
My experience of Matrix is more that it’s full of FOSS projects like Mozilla, Ubuntu, Debian, Fedora, GNOME, KDE etc… as well as lots of government users. But ymmv. If you are still seeing abusive rooms as a matter of course, please route details to [email protected], where we do actually act on them (if they are on servers we control)
Wow, yeah the parent comment is shocking to me. For me matrix is OSS discussions, like a modern IRC (not that IRC is gone, a lot of matrix rooms bridge to IRC).
Though I suppose if you search for other stuff you can find it.
Though it strikes me as a little odd, I never really associated matrix with anonymity, more with federation, end to end encryption, self hosting.
Perhaps hosting matrix servers as tor hidden services could serve that purpose.
It's a bit strange to even criticize these services for the existence of abusive users. The underlying problem is that abusive people exist in real life: it goes without saying that they'll show up in any context that's accessible to the general public.
Complaining that bad people are using Matrix is about as meaningful as complaining that bad people are driving on the highways or are filling their bathtubs with from the local water supply.
I only ever use a half dozen or so public Matrix rooms (I mostly use it for private chat) but my experience in those is nothing like you describe. Unsavory characters occasionally wander in, just as they do on every other public forum I've used, but they are shown to the door and the normal conversation carries on without them.
I wonder how someone must be using the platform, or how they're looking for rooms that might interest them, to get the impression that it's "mostly pedos and far right extremists or other weird anti social characters."
To be fair, everyone with a commute who had or has to sit in endless traffic is turned off from driving on public roads and wishes there were fewer vehicles or that they were the only one on the road.
Paraphrased, "I was driving home, stuck in traffic, and this thought occurred to me, now I know this is bad, but I thought, if half of everyone in this city died, I'd be home by now." - Paul Reiser
They'd need to specifically die in their own homes (or otherwise not on the roads), or else the resulting traffic jams would make your drive home even longer.
"What about..."? Isn't a very convincing form of argument in general and in this case it's particularly specious. When using the public roads, people's unsavory/illegal behaviour with respect to images (for example) isn't something that affects other road users, but if you're using a chat application an innocent user may well see/download content that cannot be unseen and is a crime to download (even innocently).
In that context the decision to avoid a chat application if you feel it is likely to put you at unnecessary risk where there are alternatives that will not is perfectly reasonable.
I don't mind "eccentric" personalities in my online spaces. I hate people trying to restrict online freedom more. To a degree that I think the threat of far-right people is pretty miniscule in comparison, but people allegedly trying to combat them let themselves be driven by fear. And the result is usually as bad as you could expect.
There are a lot of excuses for bad policy with the deflection of "at least I am not a far-right unperson".
A chat application usually cannot put me in any risk at all. Public personas might have different problems here, but the rules of PR aren't that new and these cases build a poor general case.
Fair to have the choice of a supervised chat app as long as people don't try to enforce all chat apps to adhere to arbitrary rules due to the latest outrage or panic over certain people, opinions, politics, bubble tea or whatever can be the source of ire.
Likewise. I ran my own MTAs for 17 years and there's nothing I want that Fastmail doesn't do - and a good bit I do that would've been (was!) at best time prohibitive to set up and run for myself.
I used Google Music heavily -- so much that my local music collection fell into disrepair. When they killed it, I downloaded everything using Takeout. Years later, I'm still dealing with the mess of metadata and (lack of) folder hierarchy that my collection used to have.
My de-Googleification of my life is nearly complete. I just wish I had done it earlier.
I've been using Hey since it was released. It's fine, but if I was going to make the switch today instead, I'd choose Fastmail or Proton instead. I use Fastmail for my business and it's been quite good. Proton conceptually feels like a better choice, but users with Proton-domain emails cause a ton of headaches (fraud, etc.) at work, so I'd probably give them a pass unless you use a custom domain.
I understood this to be the main concern with regards to harmful radiation. The article states that when HTO is consumed and comes in contact with biological molecules it binds to them and can stay in the body for years. It goes on to state the the negative effects of this may be underestimated.
There's an article like this every week or so.. I don't get it. Git isn't that hard.. You can pretty much get by 99% of use cases with like four or five commands.
The proliferation of articles like this is a very very good indication, that, yes, git is that hard, especially if you have to collaborate with other people.
Everyone has a different idea of what git does, what things are called, and different interpretations of the vast git vocabulary. What is a rebase? What is a branch? What is a reset? People have different mental models for all of these things.
Git would be easier if it weren't for all of the git users you have to work with. If you're a git solipsist, you develop your own mental model that works for you and you never have to care what anyone else does when they are using git.
I got a lot of mileage out of git with "do work on my own individual branch, never use `--force anything` even if a blog post on the internet says to, and don't rewrite history."
Reading just enough of the git-scm book to get a basic mental model of staging, branches, and pushing/pulling from a single remote (aka the things new people actually probably trying to do with git) can serve you well enough. I've since worked on teams that expected WIP commits to be squashed, used multiple remote repos, etc, but the above should be all the git most of the people complaining about git actually need.
I feel like there are two big reasons git gets the rap it does separate from any actual interface issues:
1. People tend to mess up with a tool more often when they are still getting acquainted with it. When things get hairy, people tend to just try random fixes so they can get back to work which makes the problem hairier still.
2. git might be one of the first tools someone uses that expects end users to map their mental model to it rather than trying to fit their pre-existing mental model.
Specifying the remote and branch name again when doing a `git pull` is not necessary after you've set it as the upstream branch (which the `-u` option in `git push` did in your example).
To play devil's advocate, I purposely never use push/pull without specifying the remote and branch because doing otherwise would cause issues if I accidentally forget which branch I'm on (which isn't super uncommon for me, as I've unfortunately gotten so used to seeing the branch name as part of my shell prompt that I don't notice it unless I actively look at it). I believe there's even an option you can put in your .gitconfig to enforce this.
Sorry, but it seems like you've worked in very low skilled teams. There are sometimes two different solutions to a problem, but they come with different pros and cons and you need to decide which to choose based on balancing reasons, not based on having different understandings of how git works.
For instance, when you have lots of parallel work, you have to decide whether to merge-commit each into the mainline or wether to rebase them. The first is an honest view of what happened, but might be harder to read. The other is easier to read, but might not represent well what actually happened. Git doesn't work one way or the other. Both is fine for git. And you should also be aware what it does under the hood for both options.
It's not, but if you don't use it mostly every day, or if you decide to "Delete repository and clone again" every time there's a problem, you won't ever get to learn how to fix it.
The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.
The term `checkout` is multiplexed to do more things than I would've guessed.
I find the staging area useful. It especially helps when you only want to commit a change in part of a file or just generally reviewing a commit before it's a real commit. And also to double check I'm not going to be uploading any secret keys (which seems to happen to people more often than it should).
You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit.
You don't need an extra intermediate area to review a commit. Commits are flexible and modifiable, so you can review the draft commit, modify it as necessary, and then publish it.
I always assumed it was there as an analogue of the state tracked by a UI such as TortoiseSVN's Commit dialog, or (though it's a lot longer since I lasted used it...) Perforce's changelists view. It's a list of files you've got checked out or modified: you tick the ones you want in the commit, right click to delete files or revert, double click to get a diff, that kind of thing. Between each deletion/reversion/diff/etc., the state of the tickboxes is retained, so you can sort of just fool about until you've got what you want.
But this sort of multi-step thing is often a pain to do from the command line, I find: unless you have some way of tracking the state between commands, it's no fun working through this list of items, building up a to do list that you then have to get done at the end with one uber command. And the staging area is this way of tracking the state when it comes to putting together your commit.
The gitless examples look to have many common possibilities licked, though, and perhaps that will suffice for most cases?
I didn't know about Gitless. The other interesting thing I see about it is that switching branches also switches out any uncommitted changes. On balance I think I find that less useful.
Honestly, I think that 'stash' is the more problematic concept for me. Not that it's particularly bad, just that it's extra. Make a new branch for your awful code, check out your old head and keep going. I learned hg and then git, and IIRC stash was more comfortable for my team's established workflow.
And maybe I have good reason to hate it. One of the only times I've ever broken a repo is by attempting to stash partway through a messy merge. Never did figure out if that was pebcak or a bug, or if I could gracefully recover, because I was in the middle of something. I shed a tear, nuked the repo and found a better direction to merge.
Ever since that happened I've gotten much more comfortable making and deleting branches. Among other things, they're easier to clean up and have proper histories.
> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.
I can't even imagine not having it, I extremely rarely commit all changes, to the point where I really might as well alias add=add -p, and now I've thought of it I probably will.
> The term `checkout` is multiplexed to do more things than I would've guessed.
My rule is that if I think that, I've probably got the 'wrong' mental model.
Checkout gets the state of the worktree from somewhere else.
In its simplest usage, from another ref and changes to it.
With -b, as above, but with a new branch name.
With -- files, filter for only the given files, leaving HEAD where it is because moving it would be the opposite operation - taking the inverse list of files from current location to the specified one.
> The term `checkout` is multiplexed to do more things than I would've guessed.
Do you mean `pull`?
> The staging area is totally unnecessary IMO. I think git would be easier if we didn't have it.
It's an interesting POV. Especially since you can easily amend and rebase -i before pushing without any consequence. Thanks for the idea. I implement a git-like for a special use case at the moment and will certainly consider this.
Just learn all ten and be done with it. You wouldn't work in a factory with professional tools without learning to use the tools either. So why not just learn this professional version control system in and out. It's not that hard either.
Because a lot of people have a terrible workflow. Then they spend 1 hour on StackOverflow searching a magic solution to fix their mess.
And there are also those people who inflict themselves unnecessary strict rules for whatever reason. Like those who refuse to rebase and push -f on their own branches. Or those who refuse to use a GUI but keep messing up when diffing, resolving conflicts and staging specific files/lines.
I really do not like `push -f` because in the past git default configuration was to push all branches; things have improved now that the default is to push to the current branch.
Recently got turned onto `git push --force-with-lease` which is great.
I agree it's not hard once you get it, but the main thing is people don't get it. It's unintuitive. That's not to say the model is wrong (I think it's correct), just that there's a huge gap between what people think git is doing and what it's actually doing and so they end up fighting it to do what they think it should do.
I had a coworker explain that he did a merge and something unexpected happened to his branch. I had to explain to him that what happened was totally expected and that his understanding was what was wrong.
Yeah! I find git to be easy to understand conceptually, but the CLI is unintuitive and sometimes inconsistent. I often know exactly what I want to do, but don't know how to phrase it in a git command.
Agreed. Specially, flags of these commands are actual magic when it comes to productivity, at least for me. For example, not all flags of git commit command are used frequently but they perform a lot of different operations and can be easily combined to save the day.
My thoughts exactly. Maybe it's because I've used SVM and Mercurial before but I learned Git very easily. I find the commands and options fairly intuitive once you know you're manipulating a graph of patches.
But I guess this is very subjective. After all, I've never been able to master gnupg despite how long I've been using it for.
> I find the commands and options fairly intuitive once you know you're manipulating a graph of patches.
On the contrary, I find the "graph of patchs/Merkel tree/whatever" model pretty easy to understand, and have difficulty in using the commands to make the tree look like how I want it to.
Yep. The kubelet ports were exposed. From the article:
As it turns out, our coworker’s server was also publicly exposing the kubelet ports (tcp 10250, tcp 10255). Although the problem here was obvious, it should raise some questions about your own Kubernetes deployment, as it did for us.
Its nice of you to make this long winded diatribe about security which you have gotten completely wrong.
> The content entered into the text box is accessible simply by visiting a link, which means that the data is not end to end encrypted
Me thinks you don't quite understand what end to end encryption means. When you visit pass.sh it forces you onto a TLS session. Anything you enter into that box is encrypted in transit. The data is encrypted in the database, and the password deletes itself from the database automatically after X views and/or X days.
I expected more from a "senior engineer at Virtu" but now I know what company to stay away from. Thanks.
Also as others have pointed out, the purpose of the project is to introduce a security control to curtail the sharing of plaintext passwords via communications channels WHICH PEOPLE ALREADY DO. At my company just last week a vendor emailed us ftp credentials in plain text. If they were to use pass.sh (that they can operate themselves) it greatly reduces the risk of those credentials being compromised due to privilege escalation from a compromised email account or the likes. This is a HIGHLY simply concept the aims to solve a RAMPANT security problem in large organizations.
After rereading my initial comment and the responses to it, I absolutely agree that my tone was unduly harsh and condescending. I did not at all intend that when I wrote the comment, but it was clearly the result regardless. I apologize to everyone in this thread for not communicating my concerns more constructively. I have tried to reply to each comment in a much more constructive way.
-----------------------
Creating a secure connection between the browser and your server using TLS is clearly important, but does not provide end to end encryption.
First, let’s agree on the definition of end to end encryption.
On Wikipedia article [1]:
> End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation
On the Signal homepage [2]:
> Signal messages and calls are always end-to-end encrypted and painstakingly engineered to keep your communication safe. We can't read your messages or see your calls, and no one else can either.
End to end encryption means that the contents of a message is encrypted by a sender before it leaves the sender’s device and can ONLY be decrypted by the intended receiver. The application servers, communication channel, unintended recipients, etc all do not have the ability to read the plain text content of the message.
In the context of the Pass.sh application, there are three (3) parties: the user who wants to send a password to someone (“the sender”), the Pass.sh application servers (“the servers”), and the user who the sender wants to send the password to (“the receiver”). This is the data flow for the Pass.sh application:
1. the sender enters some plain text content into the text box on the website
2. the plain text content is sent to the servers via a secure TLS connection
3. After resolving TLS on the servers, the plain text is available to the application, where it is encrypted and stored in a database.
4. The application presents a link to access the plain text to the sender.
5. The sender emails the link to the recipient.
6. The receiver reads the email and clicks on link.
7. Without authenticating, the receiver is shown the plain text.
In order for this to be end to end encryption, only the sender and the receiver should be able to read the plain text password. However, since the Pass.sh servers can also read the plain text content, this solution, by definition, does not use end to end encryption.
In step #3, the plain text is available to the servers, which means that it is also available to a huge range of potential parties: whomever is running the servers, application audit logs, any front end proxies that might be in use (e.g. Cloudflare, AWS, etc), a third party metrics or logging service that the servers might be using, or the servers could be flat out malicious and send the plain text off to someone collecting passwords for nefarious use. All of these are completely transparent to the user, so the password could be compromised even if the sender and the receiver both observe the “correct” behavior; they have zero guarantees that the password has not been compromised as soon as it is sent to the servers.
It would be a huge improvement to the security UX if the Pass.sh homepage made it clear to users that the servers can read the plain text password that they enter into the input box. Also, it would likely help users if Pass.sh provided much more written explanation about the use-cases that it believes Pass.sh can securely address.
---------------
Response to potential questions/comments:
“Well, okay, we might have the plain text password in step #3, but we don’t know the username, so it’s fine”.
Correct, you only have the password, but that is already a huge problem. For example, hackers could easily cross reference the provided plain text password against previously obtained data breaches from other services to check for positive hits. Users reuse passwords all the time (even though they shouldn’t) and the chance of getting a positive hit on a user provided password is likely much higher than brute forcing.
“Well, the code is open source, so I know that it is not doing anything malicious and can be trusted.”
Assuming that we agree that end users cannot trust versions of Pass.sh which are hosted by an unknown party because they cannot guarantee which code is actually powering the service, the argument could be made that Pass.sh is safe if you run the software yourself because it is open source and you can review the software. Of course, if you review the application code yourself and are confident in the security of the service, that is an improvement for you as a developer. However, this will only increase the trust level for users who know for a fact that you are trustworthy and are hosting the version of Pass.sh with which they are interacting.
The Pass.sh service is publicly available on the internet for anyone to use and claims on the homepage that it is “Secure Password Sharing Service”. End users cannot trust that the publicly available version is secure because they cannot guarantee that the code powering that service matches the open source code available for review. If the users could verify that the end to end encryption was taking place on their device before any data was sent over the wire, that would drastically reduce this risk. This is the main reason that I think the Pass.sh project would better serve end-users by not providing a publicly hosted version and instead instead targeting developers who have the ability to audit the software themselves to run it if they believe that it solves a problem for them or their organization.
“Using Pass.sh is good because it is more secure than sending a password via normal email, which is what users are doing right now, because the password is deleted after X time or Y views.”
I absolutely agree that the ephemerality of messages on Pass.sh means that it is more secure to send a password using Pass.sh than via normal email. However, this is missing the point. Just because A is better than B does not mean that A is good. Sending passwords via plain email and by Pass.sh link in an email are both insecure methods of sharing passwords and end users should avoid them both. Instead, they should use one of the many tools (e.g. password managers) which solve the problem of sharing passwords with other people in a significantly more secure way (e.g. end to end encryption). They could even use a free solution like Signal [2] which provides end to end encryption. Yes, the password will stay in the receiver’s message thread forever, but you have to trust the receiver to send them a password via any channel in the first place.
------------
Security UX
The home page has the text “go ahead, i'm not looking…” on it. While this might be intended as cheeky marketing talk, to me this presents a lack of seriousness and trust. First, as covered above in detail, the Pass.sh servers are in fact looking because they can see the plain text of the password. Second, normal non-technical users may read that text and believe that Pass.sh truly cannot look at their password. This is setting up a false sense of security that normal non-technical users likely do not understand the risks they are taking.
It would be great if Pass.sh provided an explanation of the security architecture for users to review. This would help people understand how the service functions and they could make a more informed decision whether it met their needs or not. Currently, someone would need to either have a technical background and/or audit the code in order to get even an overview of how the service works.
