3 ms·

I would like to urge the Google team to solve one aspect of this problem, forever. It takes no more than 20 minutes to prototype and then approximately 1 day t

I would like to urge the Google team to solve one aspect of this problem, forever. It takes no more than 20 minutes to prototype and then approximately 1 day to fully test the final solution that is necessary on their end to keep compromised emails from being fully compromised addresses forever, without any chance for you to ever know at any point in the future where mail REALLY comes from. Here is a description: 1 - Currently they (Google) correctly do 99% by allowing you to type a + after your email address to create a new inbox that is marked in a special way. For example if your address is jsmith747@gmail.com then you can give the company jsmith747+docusign@gmail.com when you sign up - that inbox goes to you and when you start receicing spam in the future to "jsmith747+docusign" you can tell how they got it. The phishing mails associated with this breach would have gone to the same place. 2. The one and only problem with this, which currently has a "security through obscurity" solution, is that anyone can run a regex and remove +docusign to get at the primary, main inbox: jsmith747@gmail.com 3. The full and complete solution is to allow me to create a new inbox in Gmail through a single step, for example "j45rsdfjdocusign" which is linked to jsmith747 in a single direction. Sending mail is not necessary. This must be enabled through the Gmail interface for signed-in users who wish to create a new inbox. They must be able to generate an inbox there, which thereafter goes to the inbox. 4. Spammers have no way to programmatically get the original underlying address when going through a list. When they get to j45rsdfjdocusign there is no regex they can apply to get the original. 5. If in the future j45rsdfjdocusign starts getting spammed, etc, you can add a filter. There's no special authentication around it, anyone signed into their inbox should be able to do do it. They already have the infrastructure up for it around their + coding shceme. To emphasize how important it is, here is a comment from this thread: >The phishing emails had the color scheme changed, making them very phony and easy to classify. Today. Under the current status quo, if in 48 months a much more legitimate-looking mail is sent to any of the same addresses, none of the recipients have any way to know the source of those addresses. However, after solving this security issue, in 48 months anyone receiving even a very convincing phishing email could know instantly "oh, that is that compromised docusign account" -- that is, if they haven't taken a moment to redirect that inbox to the trash already via a filter. I urge Google, who has very talented engineers, to implement the correct solution today. Don't wait. You won't get a better example of how important this is, than what's been going on. There are no policy implications as you already do it via the + trick. I hope you go the extra mile and add a small step to finish solving the problem. Thank you.

throwanem 9y ago
There are indeed policy implications. Each such alias reduces the available namespace, where +-aliases do not. If I had to guess why Google doesn't implement this feature, I'd guess that's the reason - their namespace is already hotly contested enough. (Of course, you can do this, quite easily, if you run your own mail domain. You need not administer an MTA - I gather you can wire up a domain you own to Google Apps or G Suite or whatever they're calling it this week.)
- logicallee 9y ago
  All right, I'll grant you that, though it's minimal: since anyone can create any number of gmail addresses already, there is a minimal policy difference. If this is a concern then Google can generate an immutable part of it (with high entropy), for example I said "j45rsdfjdocusign " of which "j45rsdfj" may be generated and the user may rewrite only the end of it. The reason it's good for the user to be able to write at least part of it is so they can include the tag and not have to add it as a separate step. Otherwise, it is hard to remember where tags go. An alternative is that during the generation the user could supply their comment which is visible only to them. (So that under this scenario j45rsdfj is generated, and you comment it with "docusign" during generation. Then if j45rsdfj receives email it is tagged with "docusign" (the comment you added during generation). There are no other policy implications. (Though I say that with a bit more hesitation, since you did point out one minimal effect.) By the way this has an additional benefit. Most user-chosen names don't have enough entropy. If I sent an email right now to johnsmith433 there is a 100% chance that it has already been registered by someone. Today, spammers can guess email addresses. (This is a theoretical problem only.) If Gmail generated high entropy as part of this feature, then this would further reduce this (theoretical only) avenue for spam. I don't think this is an actual problem though - I've never heard this being described as an issue.
  - sethammons 9y ago
    There is one thing you are forgetting, and that is working with data at scale. That is not to say it is not solvable, but it requires more thought than just shitting it out in an afternoon. Gmail as the receiving MTA will want to accept or reject a given email recipient. To do this they need to look up the information. They likely have a fancy distributed way of doing this now. If each user now exploded out to N aliases, you are likely adding a new network hop and loads more memory storage before the MTA can accept/reject. When you are processing many billions of email (lookups), this is a significant change. Again, it is solvable if they wanted to do it. But it is nontrivial. Add onto this the need for the product team prioritize the work, other work to be de-prioritized, planning, testing, etc.

throwanem 9y ago

There are indeed policy implications. Each such alias reduces the available namespace, where +-aliases do not. If I had to guess why Google doesn't implement this feature, I'd guess that's the reason - their namespace is already hotly contested enough. (Of course, you can do this, quite easily, if you run your own mail domain. You need not administer an MTA - I gather you can wire up a domain you own to Google Apps or G Suite or whatever they're calling it this week.)

logicallee 9y ago
All right, I'll grant you that, though it's minimal: since anyone can create any number of gmail addresses already, there is a minimal policy difference. If this is a concern then Google can generate an immutable part of it (with high entropy), for example I said "j45rsdfjdocusign " of which "j45rsdfj" may be generated and the user may rewrite only the end of it. The reason it's good for the user to be able to write at least part of it is so they can include the tag and not have to add it as a separate step. Otherwise, it is hard to remember where tags go. An alternative is that during the generation the user could supply their comment which is visible only to them. (So that under this scenario j45rsdfj is generated, and you comment it with "docusign" during generation. Then if j45rsdfj receives email it is tagged with "docusign" (the comment you added during generation). There are no other policy implications. (Though I say that with a bit more hesitation, since you did point out one minimal effect.) By the way this has an additional benefit. Most user-chosen names don't have enough entropy. If I sent an email right now to johnsmith433 there is a 100% chance that it has already been registered by someone. Today, spammers can guess email addresses. (This is a theoretical problem only.) If Gmail generated high entropy as part of this feature, then this would further reduce this (theoretical only) avenue for spam. I don't think this is an actual problem though - I've never heard this being described as an issue.
- sethammons 9y ago
  There is one thing you are forgetting, and that is working with data at scale. That is not to say it is not solvable, but it requires more thought than just shitting it out in an afternoon. Gmail as the receiving MTA will want to accept or reject a given email recipient. To do this they need to look up the information. They likely have a fancy distributed way of doing this now. If each user now exploded out to N aliases, you are likely adding a new network hop and loads more memory storage before the MTA can accept/reject. When you are processing many billions of email (lookups), this is a significant change. Again, it is solvable if they wanted to do it. But it is nontrivial. Add onto this the need for the product team prioritize the work, other work to be de-prioritized, planning, testing, etc.