Integration points increase the risk of compromise. For that reason, I never use the desktop browser extensions for my password manager. When password managers were starting to become popular there was one that had security issues with the browser integration so I decided to just avoid those entirely. On iOS, I'm more comfortable with the integration so I use it, but I'm wary of it.

The problem is that the UX with a browser extension is so much better.

I also find it far easier to resist accidentally entering credentials in a phishing site... I'm pretty good about checking, but it's something I tend to point out to family and friends to triple check if it doesn't auto suggest the right site.

Exactly. Same principle of passkeys, Yubikeys and FIDO2. Much harder to phish because the domains have to match.

I’m impressed with their feature to add the URL for next time, after manually filling on an unmatched URI. Hairs raised on neck clicking confirm though.

Importantly IMO is the extra phishing protection that the UX is really nice if and only if the url matches what's expected. If you end up on a fake url somehow, it's a nice speed bump that it doesn't let you auto-fill to make you think, hold on, something is wrong here.

If you're used to the clunkier workflow of copy-pasting from a separate app, then it's much easier to absent-mindedly repeat it for a not-quite-right url.

The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.

I have 1Password configured to require password to unlock once per 24 hours. Rest of the time I have it running in the background or unlock it with TouchID (on the MacBook Pro) or FaceID (on the iPhone).

It also helps that I don’t really sign into a ton of services all the time. Mostly I log into HN, and GitHub, and a couple of others. A lot of my usage of 1Password is also centered around other kinds of passwords, like passwords that I use to protect some SSH keys, and passwords for the disk encryption of external hard drives, etc.

> The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.

Also a great way of missing out on one of the best protections of password managers; completely eliminating phishing even without requiring thinking. And yes, still requires you to avoid manually copy-pasting without thinking when it doesn't work, but so much better than the current approach you're taking, which basically offers 0 protection against phishing.

My approach is that for critical sites like banking, I use the site URL stored in the password manager too, I don't navigate via any link clicking. I personally am fine with thinking when my entire net worth is potentially at stake.

It's not only about how you get there, but that the autofill shows/doesn't show, which is the true indicator (beyond the URL) if you're in the right place or not.

Rouge browser extensions for example could redirect you away from the bank website (if the bank website has poor security) when you go there, so even if you use the URL from the password manager, if you don't use the autofill feature, you can still get phished. And if the autofill doesn't show, and you mindlessly copy-paste, you'd still get phished. It's really the autofill that protects you here, not the URL in the password manager.

You don't need a autofill for a indicator. Simply bookmark your banks login page, even if it gets silently redirected later you will notice as the page wont be bookmarked anymore.

> even if it gets silently redirected later you will notice as the page wont be bookmarked anymore

What? Are you not talking about browser bookmarks? They don't change because the target website starts redirecting somewhere, at least not the browsers I typically use.

In firefox at least the bookmark star indicator disappears if you leave the site and the url does not match the orignal bookmarked anymore = phishing protection without installing more unnecessary software and increasing attack surface.

If you have rogue browser extensions installed, the browser extension can surely read the values that got filled into the login page without having to redirect to another site.

Not necessarily, a user could have accepted a permission request for some (legit) redirect extension that never asked for content permission, then when the rogue actor takes over, they want to compromise users and not change the already accepted permissions.

Concretely, I think for redirect browser extension users I'd use "webRequest" permission, while for in page access you'd need a content-script for specific pages, so in practice they differ in what the extension gets access to.

In Safari on iOS I have all the main pages I use as favourites, so that they show on the home screen of Safari.

Likewise I have links in the bookmarks bar on desktop.

I use these links to navigate to the main sites I use. And log in from there.

I don’t really need to think that way either.

But I agree that eliminating the possibility all-together is a nice benefit of using the browser integration, that I am missing out on by not using it.

Which works great until tags.tiqcdn.com, insuit.net or widget-mediator.zopim.com (example 3rd party domains loaded when you enter the landing page from some local banks) get compromised. I guess it's less likely to happen with the bigger banks, my main bank doesn't seem to load any scripts from 3rd party as an counter-example. Still, rouge browser extensions still scare me, although I only have like three installed.

Also, you want to avoid exposing your passwords through the clipboard as much as possible.

On unix-like OSes you can use `xsel` and configure it to clear clipboard after a single paste and/or after a set period of time.

> The problem is that the UX with a browser extension is so much better.

It's better, but calling it so much better [that it's unreasonable to forgo the browser extension] is a bit silly to me.

1. Go to website login page

2. trigger the global shortcut that will invoke your password manager

3. Your password manager will appear with the correct entry usually preselected, if not type 3 letters of the site's name.

4. Press enter to perform the auto type sequence.

There, an entire class of exploits entirely avoided. No more injecting third party JS in all pages. No more keeping an listening socket in your password manager, ready to give away all your secrets.

The tradeoff? You now have to manually press ctrl+shift+space or whatever instead when you need to log in.

The tradeoff is that you need to know how to setup a global shortcut or even know it's even possible. I wish people would stop minimizing the knowledge they have as something everyone just knows.

How do you set up this shortcut? I'd prefer to get rid of extensions, if for no better reason than sometimes it switches to my work profile and I have to re-login

On iOS I feel I have less control over what's running than on Linux (dont get me started on Windows or Android). So that's the order of how I dare to use it. But a supply chain attack: I'll always use a distributed program: the only thing I can do is only use old versions, and trusted distribution channels.

In theory the browser integration shouldn’t leak anything beyond the credentials being used, even if compromised.

When you use autofill, the native application will prompt to disclose credentials to the extension. At that point, only those credentials go over the wire. Others remain inaccessible to the extension.

>> Then before you know it, the devops folks have decided that they need to put a gazillion other services and an entire software-defined networking layer on top of it.

I don't work that closely with k8s, but have toyed with a cluster in my homelab, etc. Way back before it really got going, I observed some OpenStack folks make the jump to k8s.

Knowing what I knew about OpenStack, that gave me an inkling that what you describe would happen and we'd end up in this place where a reasonable thing exists but it has all of this crud layered on top. There are places where k8s makes sense and works well, but the people surrounding any project are the most important factor in the end result.

Today we have an industry around k8s. It keeps a lot of people busy and employed. These same folks will repeat k8s the next time, so the best thing people that who feel they have superior taste is to press forward with their own ideas as the behavior won't change.

In enterprise, you have little chance of getting the real story from end users in many cases. IT will also tell you that things are used one way, only for analytics to tell you it's the opposite. If you spend some of your UX research budget to deep dive on the area you can then finally get to the bottom of it.

I think the root of the complaints here is prioritization. The things they care about are prioritized. Qualitative feedback is likely already telling PMs that something is wrong and really should be fixed, but other feedback has more data supporting it.

The reality is that most product leaders only care about the feedback that has visible consequences. If users aren't performing some action like quitting the app that shows in the telemetry, then they aren't going to pay attention.

They'd probably call the issue you see a "craft" issue. Some PM is likely raising it. What happens is that leaders in big companies want perspectives based on data. You can go in with issues like yours but if you don't have clear data that shows significant numbers of users leaving, or users piling in, then you might as well not show up. People care about craft primarily will really struggle in these large organizations. That's not a good thing but how it is.

In large organizations, you'll see a lot of A/B testing or experimentation. Some of the worst decisions from a craft perspective are ones where they only look for "did this cause some kind of negative impact on numbers?" situation. If your feature is neutral (on abandons, uninstalls, or whatever negative outcome), then it can get shipped which overrides any qualitative question around "should we ship this in this state?". Doesn't matter too much according to these folks because it's not making things worse (in terms of numbers.)

There is probably more to explore in modern "product management" that's at the root of many of these problems. HN tends to focus on engineering but within large companies there is now a bifurcation and development of a field that forgets lots of PM was already invented.

These kinds of issues cause a negative feeling towards the product in the user. They keep using the product even after having seen a badly auto translated review from a language they speak or all these other things, but they now have a little bit more resentment towards the product. It makes them a bit more likely, over time, to switch to a competitor. Maybe they vent to a friend a month later and the friend suggests giving Apple Maps a try.

How do the metrics you speak of capture these subtle, delayed effects?

My point is that they don't capture the effects you describe - unless designed in. There is little motivation to do that though because they can track larger effects which are aligned with current leadership priorities. That's why I included the part about the PM that has recognized the problem.

I can guarantee you that the class of problem you describe has been discussed at the individual contributor level, so is known to some extent. Getting it from recognition to action is the problem. It is a huge lift to get some of these small things through the gauntlet to execution. Meanwhile, as you say, competitors with taste and attention to detail are building a better product.

This is very much a problem of large organizations. Those same PMs at a small company. If Google Maps was an independent company, the impediments would be fewer and priorities more aligned with building the best Google Maps.

I don't think this is always true, but it's true a lot. I think there are better descriptions than moronic as well. People use moronic when people are just as smart but have a different (and possibly better) direction. It's just the case that it defies the will of the other person.

These people go to the extreme and feel they have to outdo each other in an arms race to win whatever category it is today.

You can have extreme ambitions without being a moron. It's possible for someone to be empathetic, but also really driven. The problem is that they are locked in a downward spiral and they can't possibly be vulnerable. It's only when they run out of money, or some other extreme event occurs that they change tack. That's moronic, especially when the outcomes are predictable.

There is a lot to be said about SV culture and the people that surround these VCs. A lot of people love these environments and more than tolerate the environment these VC folks create. It's hardly a new phenomenon.

> How are they supposed to fund development?

By people buying the software. That's how it works for plenty of game devs, especially indie ones

SQL Server 2000 was well received in the segments that mattered as a challenger. Oracle was in first place running on Unix. However, it was viewed as expensive and the procurement experience was regarded as unpleasant. People wanted competition even if they didn't think SQL Server, or another alternative, could unseat Oracle for the most important stuff.

Windows was really picking up steam and there was a move to web development in the Windows-based developer space. Visual Basic and Delphi were popular but desktop development had peaked. ASP was for building your apps and SQL Server was the natural backend. SQL Server fed off this wave. It wasn't dislodging Oracle, but rather than every app being built on Oracle, more apps started to use SQL Server as the backend.

Then ASP.NET appeared on the scene and demand grew even more. It was a well-integrated combo that appealed to a lot of shops. I started my career in a global pharma and there was a split between tech budget. IT was a Windows shop for many reasons and ran as much on SQL Server as possible. R&D was Unix/Linux with Oracle. There was a real battle going on in the .NET vs Java (how about some EJB 1) and the databases followed the growth curves of both rather than competing against each other.

The SQL Slammer worm brought a lot of attention to the product. There were instances running everywhere and IT didn't expect so much adoption. Back then you had a lot more servers running inside offices than you do today. My office was much like my homelab today. This validated the need so the patches got applies, IT got involved in the upkeep, and adoption continued to grow.

Oracle's sales folk and lawyers were horrible to deal with. I had some experience of this directly as they tried pushing Java-related products and my boss dragged me into the evals. One of my in-laws was outside counsel in the IT space doing work with enterprise-sized companies. He claims they are the worst company he's ever had to deal with and wouldn't delegate any decision-making locally which endlessly dragged out deals. They had a good product but felt they could get away with anything. Over time he saw customers run lots of taskforces to chip away Oracle usage. This accelerated with SaaS because you could eliminate the app AND Oracle in one swoop.

>> And "the community" isn't moving to Codeberg because Codeberg can't support "the community" without a massive scale up.

People have a superficial knowledge of the space (I think this extends beyond Codeberg) but feel strongly that they need to advocate for something. Codeberg themselves seem to have opinions about what they want to do but people are suggesting they can do more simply because it gives them an outlet.

The constraints that Codeberg set seem to, on the surface at least, ensure they can scale based on their needs and protect them from external threats. Hosting random sites comes with a range of liabilities they probably understand and want to avoid right now. There are EU regulations which can be challenging to handle.

One issue is that 95% of the integrations will be fine with the default configuration. The others including some with high profit potential will have weird configs that will frustrate your customers the first time they try if not well tested/documented. It's better to take time and get it right. Enterprise customers love piloting and spending time, so best to approach that the right way too. Going with less complex options, that arguably have better APIs, makes it easier to develop your core product too and get real feedback from users.