HN user
fvgs.ai
I only took a brief look, but I like the premise. The service seems far from something I would trust with handling my email. I still trust Fastmail (for reference). But I strongly welcome more alternatives to Gmail and services which prioritize user privacy. The attempt at monetization strikes me as extremely premature, given the competition. But I hope to see more.
Protonmail has also given in and paid out thousands* to criminals who DDoS their systems, no?
*In my original post I mistakenly wrote "millions"
Your 1-year Standard subscription expires on Sunday, February 24, 2019.
Good timing?
Thanks for sharing, this looks neat and useful! The pagemarks are an interesting concept. It would be cool if the top progress bar above the document showed, not cumulative progress, but the progress as it maps to the areas marked on the document, which aren't necessarily contiguous. Kinda like the progress bar you have for a torrent as non-contiguous chunks are downloaded. This provides spatial information about what parts of the document have been read.
Based on the phrasing of the title, I half expected the "wheel" to be that belonging to a Tesla that somehow managed to remain engaged on autopilot for a week... would have been impressive.
That said, what's to stop a situation like that from arising as autonomous vehicles become more sophisticated?
Fastmail has worked well for me with custom domains. It's nice being able to create custom aliases for when an address is publicly visible e.g. GitHub so I know through what funnel emails are coming from.
Like others have said, the Android app is not worth installing unless you're okay with limited and, in some cases, poor functionality.
I suppose you can set it up with the Gmail or Outlook Android apps? I've never tried, as this defeats the purpose of not having those companies as your email provider :)
Still searching for a good Android mail app...
Yeah, the primary benefit I see is if one fully audits the code and any future updates. Otherwise, self-hosting doesn't confer much in the way of guarantees for security or privacy.
On what are you basing these expectations? Uploading means transmitting data to a third party. One could write a CLI that does just that. One could also write a web app where the processing takes place in the browser and the data never leaves the machine.
The difference is the web app runs within the browser sandbox while the CLI executes with user permissions.
Why would you broadly assume an incorrect rule? Email address parsers correctly implement canonicalization rules that consider the domain e.g. gmail. It doesn't require any extra work as a developer and the logic is hidden behind the abstraction. But certainly, you shouldn't go implementing arbitrary rules that aren't reasonably applicable.
The creator mentions in another post that the service does indeed upload the data to a server for processing. But, in general, it being a web app doesn't mean it uploads your data any more than a locally run application might. A web app can just as well do the processing in the browser without it ever leaving your machine.
By canonicalization I'm not saying any arbitrary practice by Gmail or any other email provider should be considered as standard. I haven't looked at the RFC in some time, but I don't believe the use of plus suffixes is standard either. Nonetheless, I believe plus suffixes are more commonplace, generally permitted, and serve a reasonable purpose. For instance, sending email to a user using their email address as provided is a good practice in order to preserve a plus suffix which may aid the user in organizing their email. At the same time, canonicalizing email addresses in a sensible way, e.g. stripping plus suffixes, can be an aid for preventing unintentional, duplicate sign-ups. Just consider a sign-up form on the homepage of a website. It's not uncommon for people to enter their email and password into that form by mistake thinking they're signing in. Additionally, if the website compares canonical email addresses when checking login credentials, then a user who signed up with an email address containing a plus suffix can sign in using their base email. These two situations combined could lead to the accidental creation of a duplicate account if canonical email addresses are not compared during registration. There are some trade offs with this strategy, but as long as the canonicalization is implemented reasonably, I see it as an aid to the user. Note that reasonably doesn't necessarily mean stripping dots.
As for the second point, I consider it a privacy breach if a service publicly associates my email address with their service without my consent. Sign-up forms do this when giving different responses when an email address is registered vs not registered.
As for how to handle it, if a user signs up with a new email address, you send them an email to verify their email address and instruct them to check their email. Similarly, if a user attempts to sign up with an already registered email address, you send them an email letting them know they already have an account and instruct them to check their email, which will provide them with a link to login.
In the latter case, if they enter the correct password, you can just directly tell the user they already have an account, as they've proven their identity.
The article shines light on three separate failures on Netflix's part:
1. Canonicalize email addresses
Whether or not dots or +asdf is considered okay, an email address used for identification needs to be canonicalized in order to avoid duplicate sign-ups.
2. Never leak information through sign-up forms
A login attempt either succeeds or fails. That is all the user should know. Telling the user if the attempted email address exists or does not exist is a privacy breach and a security breach as demonstrated in this article.
3. Never assume ownership of an email address until it is verified
Some services verify email addresses at some point in the user flow, some never verify, and few verify at the right point. The best sign-up flow I've seen is Slack where setting a password is part of the email verification flow and a user cannot set a password and own the account until they have verified the email address.
Thus, sending transactional emails beyond verify your email or reset your password before the email address has been verified opens one up to security breaches as in the case of Netflix.
Just curious, why would you want to self-host it?
Perfectly reasonable. I would then suggest changing it from "Contact Us" to "hello@hreftools.com" to prevent any confusion (Principle of Least Astonishment) :)
Looks neat! My one critique is the Contact Us link. I find unexpected mailto: links annoying because they cause my desktop mail client (which I don't use) to open unexpectedly when I'm expecting to be taken to a page, in this case a Contact Us page.
Thanks!
Thanks!
Everything I've read about hosting one's own mail servers indicates, other than the educational rewards, it's not a practical idea.
But along those lines, I was considering sending emails using Gmail or Fastmail's servers. I'm unfamiliar with the potential pitfalls, if any, when going this route. I'm hoping someone can comment on that or share their experience.
Do you know how SES stacks up against services that focus solely on email?
It looks like a great deal if you already use EC2 because of the free 62k outgoing emails/month. But there doesn't seem to be a free tier otherwise.
This video on the use of Finite State Machines in the context of React/JS may be of interest:
Just like it's acceptable to reboot a computer without a user's permission, losing all their work
This is something I've found fault with in Windows, and was greatly disappointed to see happen in Sierra.
I had been getting the High Sierra update reminder notification once a day for several days and normally just clicked "Remind me tomorrow" (since there's no option for "Don't remind me"). One day after having it pop up, I instead clicked "Try in an hour".
I expected this to ask me again in an hour, at which point I would choose whether or not to proceed with the update. Instead, while my MacBook was asleep with work open, it went ahead and updated the OS without my consent.
I don't (think) I lost any work, as I typically save things and Vim didn't leave any swp files. But the experience was disconcerting and bitterly reminiscent of Windows...
I experienced a similar disappointment after installing one of the Sierra security updates. It introduced some external display issues [1] which to this day have gone unfixed. I've spent hours with Apple support, both in chat and over the phone, explaining the issue and providing them with debug data. They told me multiple times it was being looked into by engineering and would continue to update me. But time and time again they would schedule a follow-up phone call that never came or tell me I'd receive an email follow-up that would never arrive.
I also echo the sentiment that it's difficult finding a practical alternative.
[1] https://apple.stackexchange.com/questions/277967/major-issue...
I didn't realize the page scrolled (due largely to the static footer) until I read this comment
I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant.
It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack.
I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.
One of my most used shortcuts is Cmd+L/Ctrl+L to highlight the URL bar in browsers. This is a default in most browsers
My question asks if it is possible to use Telegram's API to communicate with someone in a way that does not require the user to create or authenticate with an account. But it may require a loosely permissive authorization token provided by the person with whom the user wishes to communicate.
Intergram achieves this (if I understand correctly) by using an intermediary server between the user and Telegram's API.
What I'm further asking is if the same behavior is possible without the intermediary server.
Does the Telegram API offer any way for direct ephemeral communication between users and Telegram's servers so as to not require an intermediary server?
It may make sense to publish a self-contained component in an npm package
I was looking at Zoho earlier and I think they present themselves well. The ones I've heard most about are Fastmail and Protonmail, especially on HN.
One of the good things I've read about Fastmail and Protonmail is they are incredibly reliable and privacy conscious. Likewise, they seem to focus primarily on email as opposed to Zoho which seems to offer a variety of services aimed at businesses. I wonder if the email service offered by Zoho for private email users holds up to that offered by Fastmail and Protonmail?