|
Authored by: Anonymous on Tuesday, July 02 2013 @ 10:00 PM EDT |
Really?
Tell me how you write a service that listens at a specific
URL, and returns an "encrypted" e-mail address that can be
read by the intended party but NOT by any other party
hitting the same URL, without doing anything to authenticate
who the receiving party is in any way.
SSL (for example) will offer protection from being
snooped/MITM attacks, but that's not the problem here.
Whether I'm passing back a plaintext e-mail or an
"encrypted" one, if the "right" user's browser can access
it, then the "wrong" user's browser can access it equally
well.
I could imagine a lot of better solutions if we relax the
"pre-populate the e-mail address on the form" as the goal
(e.g. a "smart" form that only shows the "enter an e-mail
address" if the service tells us there's no e-mail on file).
But that's changing the problem.
My point is that "you should have encrypted the e-mail
address" isn't the right criticism. It's "you designed a
brain-dead solution to collect the data you needed."[ Reply to This | Parent | # ]
|
- Ask Google - Authored by: Anonymous on Tuesday, July 02 2013 @ 11:20 PM EDT
- Ask Google - Authored by: Anonymous on Wednesday, July 03 2013 @ 01:42 AM EDT
- Ask Google - Authored by: Anonymous on Wednesday, July 03 2013 @ 03:07 AM EDT
- Ask Google - Authored by: tknarr on Wednesday, July 03 2013 @ 10:22 PM EDT
- wrong - Authored by: mtew on Wednesday, July 03 2013 @ 11:22 AM EDT
- How? - Authored by: Anonymous on Friday, July 05 2013 @ 12:01 AM EDT
- How? - Authored by: Anonymous on Friday, July 05 2013 @ 12:23 AM EDT
- How? - easily - Authored by: mtew on Friday, July 12 2013 @ 12:36 PM EDT
|
|
|
|