Seems odd to me that they would encourage allowing 3rd party sites to read all your email, but I guess this is where we're at right now
- host your own email...
- on your own hardware...
- with your own software (hopefully doing end to end encryption)
Even then your surely not running your own fiber, though things like STARTTLS help mitigate this vector.
I only mean to say, some level of trust is assumed. But yea, you should aim towards less buggy, evil corporate dependencies.
They also have an alternative for the privacy-minded where you just forward any confirmation emails you want them to know about and the same stuff happens, but for the email address I was using for this, there wasn't anything I was worried about them accessing, and this was easier.
Anything that interacts with your email is going to need it, and if you're signing up for that service odds are you know (or at least assume) it'll need some kind of access to your email. For example, I used unroll.me for years, which gives you a singular interface to block spam and fake subscriptions -- for these kinds of emails, there's often no (working) unsubscribe link. Unroll.me works by looking at each incoming email and, if it's from someone you've blocked, automatically deletes the email.
Similarly, it has other services that operate on emails you receive, like bundling up multiple emails into one (which, on the backend, deletes thoseincoming emails and concatenates them into a singular email with them all later).
It's easy to say "i'll never give a third party app access to my email", but for most people it comes down to the age old problem of trading data for services/conveniences that you find valuable.
Side-note: There've been many rumors over the years that Unroll.me sells information about the emails it scans. I think it's even more telling of the "trade data for service" paradigm that people continue to use the service even after finding out.
It's not just rumors, it's stated clearly (if in softened terms) on the site now[1]. Although it wasn't for the first few years, as their original monetization model wasn't based on it.
The big stink about it was that they shifted to that model silently. The original founder only monetized it in a straightforward manner via ads in the app. Then it was sold to Slice/Rakuten, and they silently incorporated it as part of Slice's consumer intelligence data, along with data from other subsidiaries they bought such as Ebates.
Small aside: Rakuten also has a major stake in Acorn[2]. Acorn uses Plaid to verify bank account information for payouts. Plaid[3] is incredibly handy from a consumer experience, but the implications are scary from an "alternative use" perspective. Once connected, there are several handy Plaid products[4] which can make use of that authorization, above and beyond just confirming account ownership. Such as continuously siphoning off transaction level records or keeping tabs on income and employment fluctuations[5].
Not that Rakuten is leveraging their stake in Acorn to access Acorn's bank authorization for those ulterior uses. But it's food for thought on what possibilities exist.
> I think it's even more telling of the "trade data for service" paradigm that people continue to use the service even after finding out
I agree wholeheartedly with this assessment. Although I wonder how much their subscriber growth rate changed after their alternative data use came to light.
[1] https://unroll.me/your-data
[2] https://techcrunch.com/2016/04/21/paypal-invests-30-million-...
No way for me to tell whether the app that's connecting would be one I'd want reading emails (I wasn't familiar with it) and without an address bar, hard to tell if it's a spoof or the real thing.
If I accidentally clicked on a link in my email and it brought that page up, could you call it phishing?
Also the email from the person with the PDF. Like, why is that phishing? What if I trusted the sender? People send pdfs all the time. are there no secure ways to read pdfs?
The TLD of the context was .EDU and the one from the email was a .ORG.
I'm no oauth expert, but I would imagine an app would go through a flow like this.
[_] phishing
[_] legit
[X] legit, but there's no chance I will accept that!
(But personal ones? Go for it...)
I think the rationale is that the page has to be a real permissions page to give the attacker access to your data. A fake page won't have any power in that regard.
And on a real permissions page, an attacker won't be able to fake the requesting app's link.
So: legit page + legit link = no phishing ... even though it is by no means a safe situation.