Staff dev on 1Password’s developer tools here. We screwed this up in our first few releases of the 1Password CLI, largely out of ignorance. Those releases stored config in $HOME/.op at first. But early feedback pointed us to XDG, so we migrated. Now we check:
1. $XDG_CONFIG_HOME/.op (if var is set)
2. $HOME/.config/op
3. $HOME/.op
I hate to be the dev who says “I don’t know why those other code bases find it so difficult that they put up a fight” but our `findConfigDirectory()` function isn’t exactly complicated, even when you consider all the operating systems that the 1Password CLI supports.
Congratulations, you are in the top 10% for being a professional developer, correcting mistakes and not coming up with shitty excuses.
If people from this thread took notice we all could have a clean $HOME and there would be no need for this non-discussion. As you found out, it is incredibly easy to conform to the spec.
That makes no sense. You should at most have a single directory `~/.config` more and I suppose 90% of the tools writing or reading there could be configured to use ~/.${TOOL}rc
XDG didn't (IMO) make things worse, but it also didn't help as much as it should have. My `~/.config` is the largest subdirectory of `~`, because every Chromium/Electron-based application uses `${XDG_CONFIG_HOME}/$APP_NAME/Service Worker/CacheStorage` and `${XDG_CONFIG_HOME}/$APP_NAME/Cache` (and a few other cache directories) instead of sticking those in `${XDG_CACHE_HOME}/$APP_NAME`.
Exactly. It's never getting fixed, it'd break backwards compatibility now!
It's especially frustrating because it means you can't simply back up your entire `~/.config` (or wherever you pointed your `${XDG_CONFIG_HOME}`), you have to pick specific files & folders in there.
I considered it clean when everything had a single file or directory in $HOME. Some things didn't play nice but they were the exception. Now it might be that, or there might be files scattered among one or more XDG directories.
You cannot redefine words to the opposite meaning. If you want to lump everything together then Linux is not your friend.
On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
> You cannot redefine words to the opposite meaning.
I'm not. Lots of things in a directory is not inherently a mess. I mentioned exceptions, things such as bash and steam make a mess because they're not completely cleanly filed away in their own directory. In my experience most things (not all) that don't use XDG are happy to cleanly files their stuff away in its own directory, sometimes divided up further into subdirectories when it makes sense. Or a single file instead of a directory if there will only be one file.
> If you want to lump everything together then Linux is not your friend.
I don't need to be friends with a kernel, and anyway, this practice has been around on Linux longer than XDG has existed. I see no reason why it won't continue to work just fine in the future.
> On Linux we separate stuff so you can for instance backup config without having to figure out for each of 100 applications where they have stored config in 100 heaps of mud.
People use Linux in different fashions. You're free to use it how you want and I'm free to use it how I want it. Your backup scheme is not suitable for me, and I suspect mine is not suitable for you. And that's OK.
> And you are sidestepping the issue of control. With XDG you can easily and generically symlink your 100 balls of mud back with 3 lines of bash. That's because with XDG you have structure. The other way around you don´t. So don´t talk about `clean`.
Most applications in my experience have a mechanism to define where configuration is read from. That's control, not your symlink mess. Structure is done appropriately per application.
It's fine if you disagree with me. It bothers me when I'm told that my opinions are wrong, which is what your post reads like to me.
And yet you impose XDG (originally a GNOME specification) on macOS (completely unrelated to GNOME or Linux). On macOS, you should be looking in ~/Library/Application\ Support/op and ~/Library/Preferences/op/config.
I’ve got a script that I’m making conform to XDG, and it's a lot of work to make it work well because I have to know about three different roots for different things (configuration, temporary files, and persistent files). I’m not convinced that it's worth it, because it is no longer as easy as telling someone "uninstall this by doing `rm -rf ~/.PROGRAM`", but instead I have to say `PROGRAM self destruct` or something like that to clean up all the detritus (and what if it fails in the middle?).
I'm pretty sure the XDG base directory spec was not specifically a gnome thing. It came from freedesktop.org[1] if I remember correctly, and in fact gnome was not compliant to begin with[2]. That gnome wiki page references that the recommendation (which turned into the spec) came from freedesktop and documents the gnome "initiative" to become compliant. Freedesktop was focussed on compatibility between desktop environments and systems, so isn't just a linux thing.
As macOS user, I'd rather they use XDG than the "standard" macOS directories. Maybe there's a point to be made to use the standard if the XDG variables aren't set, but I'd generally avoid that for CLI apps. Having everything under ~/.config is more convenient.
Agreed. "Application\ Support" looks subjectively disgusting to me. It's the only path on my configuration with spaces. I have to use it because that's where vscode settings.json is placed.
If it helps, it may have been for a good reason. Microsoft used to name the folder that stored user directories "Documents and Settings" so developers would be forced to make sure they could handle paths with spaces in them. Now, they call that folder "Users", and I had to make sure when I set up my Windows install that my name didn't have spaces in it so a bunch of apps didn't get screwy.
Big +1, macOS has a lot of UX wins, but their config directories aren't one. Also XDG allows me to have at least some things in the same place on Linux and macOS, which may be a very niche need, but still something I appreciate.
+1 to this. I have been a MacOS-exclusive user for more than a decade now and `~/Library/Application\ Support/` is simply ugly and, dare I say, un-Apple like. It has a Window's "My Documents" vibe going on.
Xdg isnt just config. Using .config (xdg config) on Mac is super weird.
Xdg is also, .cache (xdg cache dir) for data that can be cleared on reboot allowing you to use tempfs for it (of course you can't because a bunch of shit uses it as a persistent cache for things they should be putting in .local/share/. (Xdg data dir).
This whole mess is so utterly fucked I gave up caring and just let the mess be.
> Using .config (xdg config) on Mac is super weird.
Why? Using it makes macOS more similar to Linux, which I think is a good thing. It surely makes it easier to share configuration files between Macs and Linux machines.
Honestly, I don't see a single upside to using macOS's specific directories over .config/.cache/.local.
There are operating system processes in place to help keep `~/Library/Caches` smaller (or at least somewhat constrained). They are not there for `~/.cache`.
I don't see anything saying that clearing ~/.cache on every boot is expected behavior. I see lots of real world behavior of using ~/.cache as a multi-gigabyte download cache you would not want to lose regularly.
Most prsistent files should never be cleaned on uninstall, you don't know why they're uninstalling, it could just be a reinstall to fix something. Configuration might not need cleanup either.
Temporary files often shouldn't exist. If it's less that a few megabytes why is it touching disk unless it will be needed persistently? In any case the detritus doesn't matter, if it's big enough to care I'll see the disk space is low and find it with baobab at some point.
It's not perfect, but it's not a major nightmare.
For my part, I don't always follow XDG specs, I often just create ~/AppName, but sometimes I'll make more than one to keep features within one app separate. I put IP cam recordings in ~/NVR by default, and stuff like that, because the main app dir is all stuff you would backup and restore, which probably doesn't include NVR recordings for a home user.
Has a MacOS dev, I'd prefer config like this in my home directory so I can easily access it between MacOS and Linux. My expectation for CLI tools is that config is in $HOME/.config/.
Yet…that is exactly the argument of the original post. The banner argument is that VIM is wrong because it doesn’t use `~/.config/vim` and instead uses `~/.vim` … which it has used since before XDG was created. Vim also doesn’t use ~/.vim` on Windows (and the files aren't `.vimrc` and `.gvimrc`, but `_vimrc` and `_gvimrc`.
User expectations differ. The correct place to put application detritus is `~/Library` on macOS (`/Library` if it’s system-level with no user-level). I am surprised when a cross-platform library uses `~/Library` instead of XDG, but I am not unhappy with it.
Frankly, most programs should have a command like `show-config-paths` (`--show-config-paths`) so that you can see where the configuration, caches, etc. are on the platform you’re on, and possibly be told (a) whether they are overridden from default and (b) how to override them. It would be useful to have that output for both human and machine reading.
I agree 100% on having a command to this effect. I always make sure that there is a command to show the currently resolved configuration location, as well as printing out configuration (minus secrets) when the application starts in debug mode.
Furthermore, when you do '--help', whenever it's half-way reasonable, I will show you what your currently resolved settings are for any flags/variables/configs next to the corresponding flag, as well as the default value. I actually don't know why this isn't common.
Yes. I think that the plugins should probably not be in $XDG_CONFIG_HOME, but in $XDG_DATA_HOME, if I’m reading correctly.
But in part my point is that there's virtually no one who gets this correct either with Linux systems or macOS, which is what makes rants like the parent article so annoying.
I love JMAP. It's what allowed me and my team (at 1Password) to easily add support for Masked Emails, where we randomly generate your email address in addition to your password.
I use Fastmail and 1Password, and I do used the masked email functionality. There is a massive gap, though, that makes it very difficult to rely on masked email. When I sign up for a new account somewhere, I can choose to create a masked email. If I later need to email that company (not reply via an existing email message), I must first somehow look up what email I used for that company, go into fastmail settings and create a "sender identity", remember the email address again, and then when I compose, remember to choose the sender identity that is associated with the masked email address I created for that specific company. If I forget or mess up any of those steps, I end up sending from my primary account or some other masked email address associated with some other company. Multiply that by dozens or even a hundred companies!
It would be really nice if adding a masked email automatically created a "sending identity." Further, it would be nice if the masked email account had a nickname that included the domain I was on when I created the account. That way if I need to send an email to support@nike.com, I can use the filter and type "nike.com" and get the correct masked email address.
> It would be really nice if adding a masked email automatically created a "sending identity."
It does.
Just click "... Show all" when choosing a sender, and that will expand the list/search to include masked emails. It should also show you the domain/service it was set up for. And as you noted, the masked email will automatically be used as the sender when replying to an email that was sent to it as well.
Using 1Password makes it super easy to see which masked email was used for each service, so I can't really relate to your frustrations there either.
I think it's a pretty polished experience, and definitely beats everything else I've used in the past.
Only sort of. First, this is a new feature, there used to be a whole section on adding "sending identities" and describing how to do it in order to send from a masked email address. I have support emails from 1Password pointing me to those docs as well. That whole section has been removed and now there's a note in the docs saying why (no date, though, so I don't know how recent).
Second, your description glosses over the fact that if I click the "from" address dropdown, and then in the filter/search field, type the domain associated with the masked email address, nothing shows up except "Show All." Why wouldn't a filter/search find the address? I have to click "Show All" and then repeat the search.
However, if I search/filter for any of the dozens of "sending identities" I created previously, the search/filter works correctly. So the UI is completely broken. When I search/filter something, and nothing shows up except a "Show All" button, that's the UI telling me that there were no matches. Oh, but now I learn that there are matches, they're just hidden under "Show All" (which should be renamed to "show matching masked email addresses" or something!?).
What's missing? The old experience definitely sounds pretty frustrating.
Personally, I really like that masked emails are hidden by default. I've got 20 "real" sending identities, so when I'm searching I want a quick selection that doesn't include dozens of masked results. The amount of times I start a new email thread with a masked email would probably be a small handful of times per year.
Edit:
> I have to click "Show All" and then repeat the search.
Maybe that's a bug you can report for your browser? I don't need to retype anything and just hit enter when I get no results, then it expands the results to include masked items.
This has been one of my biggest peeves about the WWW since 1993. Please include publication and/or change dates and/or include a changelog on your pages. Do not force your users to resort to reading metadata, the URL path, the Wayback Machine, or dark magic to figure out when and what changed. Diff is a solved problem; why can't I diff a generic web page?
> there used to be a whole section on adding "sending identities"
This still exists, by the way. They moved it to Settings => Migration => Import => Add alumni email forwarding address or non-SMTP sending identity, which makes absolutely no sense to me.
> go into fastmail settings and create a "sender identity"
Not anymore, they've made it much simpler for you now by combining "aliases" and "sending identities" into "my email addresses". If you thought it was confusing before when you had to click "create new" under "sender identities" in settings, now all you need to do is:
1. Head to Settings → Migration → Import page.
2. Click on Add external sending address (SMTP) without importing emails.
3. Enter the email address and click Next.
4. On the following screen, skip the password prompt and click on Manually configure.
5. Disable the option - User authenticated SMTP when sending.
6. Save the changes.
And just like that you can start sending emails with your new address, easy peasy.
A "Sender identity" should just be a different From: mail header; it shouldn't involve disabling SMTP authentication. The SMTP envelope address and authentication are unaffected.
Instead of generating a unique email per relationship, it'd be better if the email provider generated a unique key when the relationship is established that the customer or end user can revoke.
Email me at my well known identity "whoever@whatever.com" -> my provider gives you a key that you must store and continue to use for the duration of our relationship. I can terminate it if I want. If you lose the key, you must ask for a new one. If you ask too many times, I can silence you forever. You'll have to provide your own identity when asking.
For noisy environments, I can choose to give you the key upfront and only allow for that style of relationship.
I could imagine encoding the concept of entity or organization type into the keys as well so that we can distinguish individuals from companies. Professionals, academics, official employees, etc.
If you delegate your key to another party, I can choose to pre-authorize it, manually approve it, or outright deny it. Extend it haphazardly or without my consent and you may be blocked.
I'd like that type of system.
Emails shouldn't have to change. The protocol should. Getting parties onboard might be hard unless a key stakeholder (eg. Google) decides to implement this, but they're in a position to unilaterally dictate.
OK. Sure. It’d be better, for you, a technologically savvy receiver of email. I can’t see anyone else in the equation that stands to benefit from this. I can’t see non-tech-savvy email receivers caring much about this at all, or any of its effects, until it has near-universal adoption. Part of solution engineering is coming up with something that people actually want to use.
So I don’t really see it as better. I see it as pie-in-the-sky fan-fiction to address part of what masked emails aims to address. A significant portion of the time that I used masked email, it’s in service of increasing anonymity (to the organisation i am giving the email address to), not an anti-spam measure.
While the protocol details would undoubtedly be somewhat complicated, the user-facing UX wouldn't necessarily have to be.
The only part I'm not quite sure how to do seamlessly is the initial exchange. You sign up with your email at a new website, and need to also give them the unique key that allows them to correspond with you. This would require browser support, and a standardized protocol for letting the browser request a new key from your email provider. Also means your browser would need your email credentials (well, an OAuth grant, more likely). And the problem here is that, until all browsers (or whatever) support it, you'd have to run the system in a default-allow state.
Another option for the initial per-contact setup is a sort of trust-on-first-use kind of thing. First email from a new recipient is allowed through, but at that point your email client will ask if you want further emails to be allowed (and if you do, it'll send the key to the sender behind the scenes). Problem there is that spammers could just burn through new email addresses to keep contacting you.
Anyway, I'm sure there are solutions to these problems, even if I can't think of them in the 12 seconds I've allowed myself to do so. I expect this would be something that would remain disabled for a while, until all the infrastructure and client support is in place.
Also, every website would have to have a way to do this. That's a massive bootstrapping effort that, you can't change every website in the world very easily, there'd have to be a very massive advantage for them. I don't see the evolutionary pathway to get your suggestion implemented.
Besides, this already exists anyway, it's basically:
This has been a very gradual change. The earliest announcement I can find is from 2018[1] but I'm pretty sure it was in the works long before. That's more than five years to implement a technology that browsers and servers at the time already had known how to do for a decade or more.
The users don't have to interact with any piece of this. It can be 100% a backend implementation detail.
If you did want to surface it, the controls could be as simple as "block sender", "opt out of 3rd party contacts", "sender X wants you to connect with sender Y - allow?", etc. Very coarse grained, very easy and intuitive.
This was also an issue I had, but there is actually very good support for this hidden by an invisible feature. Simply add an `*@domain` as your email address identity. When you select that as your from address the fastmail UI gives you an input box to use whatever email you want, you don't need to make a new identity each time. For lookup, I just use my password manager.
Off the current topic but since you're promoting 1Password, I notice their cookie policy references EU legislation but chooses not to comply with it. Do you know if that's intentional?
Indeed that is very awkward: "European Union (“EU”) legislation requires all website operators to inform website visitors about their usage of cookies"
Later: "first-party and third-party cookies are used on: 1password.com (...)
Stating that you need consent and not asking for it is extremely weird.
The legislation requires you to ask consent for non-essential (ie. tracking) cookies. So unless they put a tracking cookie on their site the behaviour is correct, and that text is simply incorrect.
That's my bad for not quoting further, the very next paragraph is:
> First-party cookies are set by 1Password. They help calculate things like page views and visitors to the website. Third-party cookies are set by 1Password affiliates for commission and advertising purposes.
This is a CGI-scripted web application without any kind of web framework, in an original programming language.
It authenticates you using IMAP or SASL: with direct socket work in a few lines of code. (That's the only integration with IMAP.)
It manages aliases in a standard aliases file. If configured, it can work with the master /etc/aliases file, in which cases it will carve out a section of the file for itself and respect the surrounding file when it adds or removes aliases. I run a separate aliases file, though.
I do most of my mailing using the RoundCube webmail interface. I made some patches to it.
In connection with the throw-away mail aliases, the issue that comes up is that when you use them for sending, rather than just receiving mails, you want that to be available in the list of sender identities in the mail client.
While it isn't automatic, I put in a hack which at least makes it easier to identify the mail identities. In RoundCube, a mail identity has an "Organization" field: what org you belong to. There is a mail header for that, IIRC.
I changed the UI so that when you look at the identities list box, the Organization field is listed in parentheses (if it is non-blank). Then I use Organization to describe the purpose of the mail alias, e.g "Foo Mailing List" or "ABC Company".
Only a small subset of my throw-away mail aliases become sender identities; I do that manually.
Yes; this is for the control freak that wants to shut down the offenders at the SMTP level.
Plus there are some other benefits.
Each one is associated with note field. URLs in the note field are rendered navigable. I use the note fields not only as a reminder about what the alias is for but also for PW management. Throwaway mail aliases often have throwaway passwords associated with them too.
The explicitly created aliases track their creation date, which can be informative from time to time.
UI has a regex search over the aliases (any field).
because the masked email API matches the rest of the JMAP API, so it's easy to extend and support. Also, 1Password isn't running Dovecot, Fastmail is. So they're asking a 3rd party is a fairly standards conformant way to go and create a new email alias
Hi, one of the 1Password engineers who worked on this. Glad to hear that you like the idea!
One of the really nice parts of building this out with Fastmail is that you can create Masked Emails for your own domain. So, if you ever decide that Fastmail isn’t right for you, then you still receive all of those emails when you set up a wildcard alias with your new email provider.
Similarly, if you ever decide that 1Password isn’t right for you, that doesn’t stop you from receiving your emails. And the email addresses should still be part of your 1Password export.
I've had this thought for a product multiple times. I run my own mail server, and for years I've created a random email for every service. Main reason was to figure out who is selling my email addresses.
The main thing that always held me up was, how do you plan to avoid getting blacklisted at the domain level if people start abusing the ability to create random emails? A few services I use even disallow Gmail addresses.
I've had services refuse my fastmail.fm email address, with the reason that they don't allow "disposable" email accounts. But they accepted my gmail.com address....
Not that this was their criteria (they seldom if ever think it through to this level), but gmail requires phone number after a certain point. And they only allow 4 accounts per phone number.
I can't fully speak for the Fastmail folks, but I know that there are a few upper limits for how many masked email addresses that one account can create. We tried to set them unreasonably high to allow for all manner of legitimate use while still preventing bad actors. They're also monitoring usage and tuning that limit. Plus, you can always email support and ask for a increase for your specific account, if you ever bump up against it.
Sell private domains as an "enterprise" feature, and have different sets of IP blocks warmed and ready to go for when they eventually get blacklisted. But selling it as a service involves a higher level of effort due to that exposure. Configuring a private domain for just yourself to solve the problem just for you doesn't have the same risk exposure.
mailinator's been around providing this (as a recieve only) service for decades by this point.
Those +plus aliases still make it easy for people find your actual email address.
We go one step further and generate a random email address for each new service you sign up with. It'll look something like "hot.potatoes4827@mydomain.com".
You can create a new masked email anywhere you have the 1Password browser extension, including our brand new iOS Safari extension.
This is nice in terms of hiding your actual address. However, it makes migrating away harder because now instead of setting a simple rule to strip the + for forwarding, you need to individually map each address.
So what is it that you want? Either you want a masked email or you want an easy way to migrate away. You could still setup trashcan+randomdigits@yourdomain.com manually. Or you could setup a catchall rule for your new provider.
Unfortunately, way too many internet services don't allow the plus sign in an email address. It's weird, but it's true.
Even worse I've had front end systems accept account creation with this address format, but their backend system fails when using some integrated service. The result is 3 months after setting up the account something breaks when I try some other functionality and I have had to contact their help desk and ultimately we stumble through and realize the problem may be my email address.
There are varying level of masking. I would consider an email myusername+random@domain.com as a masked address. Of course it is trivially unmasked. But assuming I am willing to accept that, it does offer a different tradeoff with respect to convenience. It's true though that is fairly trivial to manually add +random
`sed s/[+].*@//` over the email list will get rid of enough "plus" email addresses. Better use a custom delimiter if you're relying on the + character for anything.
How hard is that though? Export all email addresses from 1Password (trivial), extract generated emails (trivial), and add forwarding rules for each one in your mail server (trivial to easy depending on your setup).
Maybe not easy for non-savvy users, but neither is a custom domain or even knowing about the + trick.
I have an extra domain attached to fastmail which I only use for junk. If you know the domain where my main email lives, you can pretty much guess a couple of aliases which will work. I want my junk mail completely separate from my useful mail
I ended up at https://$mydomain.1password.com/integrations/directory and I can only see Fastmail as an option. Clicking there it asks me to Connect with Fastmail rather than that I can provide my own domain. I already have a wildcard domain setup so I'd like to use it as @davzie mentioned.
You need to OAuth to Fastmail (the service) to hook it up, then as was mentioned above, you can go into the settings in your Fastmail account to choose which domain your Masked Email addresses are created in:
Settings -> Domains -> Team Settings -> Masked email domain
It will default to fastmail.com, but easy to change it.
Oh, I completely misunderstood then, I thought I could do this with just 1Password. I already have email setup myself and don't need Fastmail, so then it seems I cannot use this feature. I'll just continue myself to randomly generate my addresses then...
Well, as I understand it you'd have to do this manually. As in, pick a random alias for the site, use that as you email address there and enter the same one in 1password (or any other credential store).
The full "it just works" integration seems to only work between 1password and fastmail directly.
True! I've been doing wildcard.company.name@mydomain.com for a few years now with Fastmail. This makes it one step easier to generate that email address, as well as one-click blocking any alias that starts receiving spam.
That's the way to go. I set up a rule where everything going to *@a.mydomain.com goes into a folder which I largely ignore. Every website gets a unique prefix, e.g. ycombinator@a.domain.com.
The advantage of Masked Emails is that third parties won't even know about mydomain.com. The disadvantage is that you need 1Password to recall which email address you used with a particular website.
> Yes, but if you goal is to hide your identity, this really wouldn't work
It still could.
> Everything is still tagged to your identity, i.e. @mydomain.com.
If your domain is tied to your identity, then yes. But to be extra clear, this should have said "Everything is still tagged to your domain" as not everyone has their domain tied to their identity. I for example have my domain setup njal.la with zero personal details attached to the domain itself, either publicly or at njal.la.
A comment you made in the past or make in the future could reveal something; simply changing the text to "njal dot la" would prevent a google search of the domain from finding this.
Doesn’t that rather defeat the point though? I can set up a wildcard for fastmail and use any account name I want to sign up to services without any intervention from 1password.
Edit: saw someone point out this only works for one user per domain.
I've been a happy Fastmail customer for years prior to working on this feature. I've used a wildcard with my Fastmail account, created a new email address for each service I sign up with, and stored that email address in 1Password. All by hand. It's a tiny hassle, but one that I think is worth it.
The Masked Email integration makes that entire process automatic. It's even easier than before. It's enough to convince a few Fastmail-using friends to start doing it.
Yeah I also do this: I own my domain and I use a catch-all setup at my email provider so <anything>@jpreston.xyz goes to my inbox.
I suppose the advantage with a non-custom domain is you leak no info about yourself, the masked email is 'just another Fastmail email address'. But doing it for a custom domain feels like it defeats the point, isn't it just like catch-all at that point?
The value is in knowing who leaked your email address, and being able to take action based on that. If you use a unique address for every service then you can know for certain random Internet store got hacked, or sold their database. In either case, you kill the credit card you used (privacy.com) for that store before it gets used elsewhere, saving you additional time and money on having to deal with your banks.
Definitely! You can decide within Fastmail’s settings[0] which domain you want to use for masked emails. It can be fastmail.com, one of their fun domains like afcrichmond.uk, or one of your own. I've even seen some 1Password coworkers buy a brand new domain purely for their masked emails, so you can generate a “good.castle3827@youdontneedtoknowme.com” while still using “me@mydomain.ca” for your actual personal email.
1Password is the world’s most-loved password manager.
I’m the tech lead on the Administrator Tools team. We build products, feature sets, and tools for our most powerful users. From building usable and scalable means of managing vaults, groups, and users, to making account recovery simple, and secure, we enable administrators to manage 1Password for their entire company.
You may be a fit for the role if you:
* Are excited to learn new things as you tackle new features and make existing ones better
* Have a critical eye for detail and you understand that perfection is the enemy of good
* Show a healthy balance of being able to work collaboratively while also taking responsibility for the tasks assigned to you
* Show a penchant for clean, idiomatic code that's easy to read and maintain
* Have a strong understanding of web server and RESTful API design
* Are proficient in writing well-optimized MySQL database queries
* Know secure coding practices
* A thorough grasp of how networking works
Bonus points if you have:
* Experience with Golang. It's certainly nice, but not required. Show us that you have a great understanding of any modern programming language, and we'll trust that you'll learn Go just fine.
* Experience with JavaScript, Typescript, and/or React.js. Sometimes you’ll need to dive into the frontend to understand how a feature works.
I mean, sure, you're technically correct, but you're missing the point. For just one example, it's so heckin' convenient when an app recognizes that you have a 2FA token in your clipboard copied from your 2FA app and "pastes" it for you automatically.
Given how they've positioned Pocket and how Firefox's new tab page contains "Recommendations from Pocket", Mozilla seems to want you to enjoy browsing. They want you to enjoy using the Web and to enjoy it using Firefox. It's an interesting play and I'm excited to try it.
I understand your point, but I wanted to mention that other countries do charge for bathrooms (even NYC charges for public washrooms), so you can use a better example in the future!
> Fundzinger had a clause in their contract that if you for any reason cancel the project before the end of the campaign, they would bill you at their hourly rate.
> For Fundzinger, we got on the phone with them and explained the situation in detail. They were more than understanding, and offered a deal that worked for us.
(Not a “grrr, smartphones” post, just a sad reality post)