Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-02-02 Thread Ángel via mailop 
On 2020-01-27 at 01:42 +, John Levine via mailop wrote:
> In article <1580084583.939.2.ca...@16bits.net>,
> Ángel via mailop  wrote:
> >> I like TOTP codes because you can install the keys into multiple
> apps ...
> 
> >Not supported by Google, though.
> 
> The gmail app on my phone would be surprised to hear that, since I've
> been logging in with TOTP codes for years.
> 
> R's,
> John

Maybe they used to allow it years ago, and then removed the ability to
register it? I did check before sending that email, and found no option
for that.

The only options I am offered are:
* Text message of voice call
* Security key
* Google prompt (Get a Google prompt on your phone and tap Yes to sign in)


I would be happy to be proved wrong if there is a way I have missed,
though.

Kind regards


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-27 Thread Brandon Long via mailop 
On Mon, Jan 27, 2020 at 3:19 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:

> On 27/01/2020 08:03, Brandon Long via mailop wrote:
> >
> > The other end of this, what do you do when someone presents the right
> > password to log in, is it a hijacking or not?  What happens is a risk
> > assessment of the login, is it from the usual location?  Usual country?
> > Usual device type?  Is it from somewhere where you see a lot of unusual
> > logins?  Does it look like some automated software and not a normal
> browser?
> > How strong is the password?  How common is the password?
>
> I don't think there is a reliable way to guess, based on a computed
> password
> strength, how many blind attempts are necessary to crack it.  Even weak
> passwords seem to resist quite well.  (Yet, bots keep trying...)
>

Brute force is of course easy to prevent.  Blocking a dozen attempts from
extrapolations
of leaked passwords, less so.  And it's not really the password strength as
much as
commonality.  At a larger scale, the silly point in Hackers
 is true.  You see
things like this:
https://en.wikipedia.org/wiki/List_of_the_most_common_passwords

but the duplication goes way beyond just 25 passwords.

> This isn't about tracking, this is about keeping your data safe, and
> protecting
> > everyone else from
>
>
> As if smartphone were the quintessential secure device.  That hype on using
> smartphones for 2FA seems to be somewhat smelly to me.  Personally, I
> still use
> a Nokia 2760, which I deem safer than Android.  Anyway, cell signal is
> poor in
> my office so I really hate how everyone —especially banks— insist on SMS
> based
> OTPs.  Perhaps, G5 will bring SMS via WiFi, but for the time being
> telephone
> number is not an option for me.
>

SMS based 2FA is the worst 2FA, most hijacking paranoids would tell you not
to use
that due to sim hijacking and the relative ease of getting someone at your
carrier to
"help" you.  Google's notorious customer service seems like a benefit in
these cases,
where overly helpful customer support blithely turns over your phone line
to someone
posing as you... or pays off someone at the carrier to do it.  Mostly, it
depends on whether
or not you're a target.


> In Italy we have a number of state-issued certificates, some on smart card
> (identity card and health services card) and some just online (spid).  Last
> month a minister suggested that they could be used also by others, such as
> Google.  How controversial![*]  People reacted as if each use of the
> certificate can be logged by its issuer.  By contrast, nobody notes that
> each
> use of the smartphone /is/ logged by the telco provider.  Idiosyncratic,
> isn't it?
>

I'm not sure of the utility of an online certificate, that feels like it
falls into just another "thing that you know".
It's possible that could be used to boostrap into something that's actually
installed in the TPM on your smart phone.
Smart cards require hardware readers.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-27 Thread Luis E. Muñoz via mailop 



On 26 Jan 2020, at 16:23, Ángel via mailop wrote:


I like them as 2FA solution, too. Simple, standard, offline, vendor
neutral, not vulnerable to MITM...


Ahem. If the attacker manages to position themself in between your 
session, they get a chance at your TOTP. Same attack scenario as with 
the old RSA SecureID tokens.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-27 Thread Brandon Long via mailop 
On Mon, Jan 27, 2020 at 12:06 AM Andrew C Aitchison 
wrote:

>
> That is pretty much what I thought, and I agree that this all is good to
> do.
>
> I accept that in reality professional bad-guys are the biggest risk, but
> in my paranoia I am more afraid of what happens if my phone slips out of
> my pocket in a public place.
> Assuming the person who picks it up can unlock my phone (that may be
> unrealistic) if we have eliminated passwords then they have access
> to all my data stored anywhere.
>

I mean, passwords haven't been eliminated, they are one of the two factors.

The other factor doesn't need to be your phone.

Realistically, the person picking up your phone is either going to try and
return it
or sell it for cash.  Maybe the person down the line would do something
with it,
but usually they are just trying to wipe the phone so it can't be traced so
they
can sell it.

Anyways, I do understand the reluctance to switch to 2FA, the possibility
of losing
all of your second factor creds is frightening.  And at least once I
haven't been able
to log in at some point because I didn't have one with me (well, I had my
portable
security key, but it was the wrong type of usb for the device I was trying
to use).
It's annoying.

Brandon


> On Sun, 26 Jan 2020, Brandon Long wrote:
>
> > On Sun, Jan 26, 2020 at 10:35 AM Andrew C Aitchison via mailop <
> > mailop@mailop.org> wrote:
> >> Hmm.
> >> Proving that you can read a text sent to a number you provide today
> >> does not prove that you are the person who used the ID and password
> >> yesterday.
> >> So they demand you provide a new verification channel so that you can
> >> prove your ID *next* time ?
> >>
> >> I find these multi-factor verifications unsettling because it takes
> >> a significant effort to convince myself that the verification does
> >> indeed prove what it is supposed to prove and that it is safe from
> >> man-in-the-middle.  I have lost enough physical keys over the years
> >> to worry about what happens if I lose my phone (which does not have
> >> a finger print reader) ...
> >
> > It's hard to determine what happened based on the descriptions, but
> > the general answer is pretty simple.
> >
> > Passwords are terrible and completely broken.  They are generally
> > poorly chosen, weak, and re-used.  The result is extreme levels of
> > hijacking.  On top of that, people forget their passwords and this
> > isn't something like your home electricity bill or even your
> > bank... how does Google know it's you?
> >
> > At the one end, that makes account recovery challenging, and it
> > certainly seems that Google decides that losing your account is
> > better than giving it to someone else.  There's probably extensive
> > arguments and concerns about how exactly the draw that line, but
> > that's the tension.  Your Google account can contain multitudes of
> > personal information, granting it to the wrong person can be
> > crippling to the main owner.  Losing access can also be terrible.
> >
> > The other end of this, what do you do when someone presents the
> > right password to log in, is it a hijacking or not?  What happens is
> > a risk assessment of the login, is it from the usual location?
> > Usual country?  Usual device type?  Is it from somewhere where you
> > see a lot of unusual logins?  Does it look like some automated
> > software and not a normal browser?  How strong is the password?  How
> > common is the password?
> >
> > The end result of that risk assessment is whether to let the user
> > in, or to make the login more complicated.  That started with
> > captchas, sometimes requiring up to 5 or more of them in the
> > riskiest case.  The next level is requiring a phone number.  Better
> > if the phone number used was already known to Google, but really any
> > phone number will do because a phone number costs money to obtain,
> > so limiting how many accounts can use a number or how frequently,
> > and you have raised the cost of accessing the account.  Of course,
> > then you need to know what all of the free or almost free phone
> > number services are, to not allow those to be used, as they don't
> > cost enough.
> >
> > Of course, if there's money to be made, there's a way, so you get
> > people stealing entire boxes of sim cards and creating special
> > hardware to use them, see the pictures from this article:
> >
> https://cyberpolice.gov.ua/news/kiberpolicziya-prypynyla-diyalnist-masshtabnogo-servisu-dlya-reyestracziyi-riznyx-akauntiv-u-mesendzherax-soczmerezhax-ta-poshtovyx-servisax-8596/
> >
> > This isn't about tracking, this is about keeping your data safe, and
> > protecting everyone else from what can be done with a hijacked
> > account, from sending spam to click fraud to YT abuse to bitcoin
> > mining on GCP.
> >
> > In many respects, actually setting up 2FA on your account puts you
> > in a better situation.  It means that access to your account is hard
> > to abuse, and so the risk assessment is completely

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-27 Thread Alessandro Vesely via mailop 
On 27/01/2020 08:03, Brandon Long via mailop wrote:
> 
> The other end of this, what do you do when someone presents the right
> password to log in, is it a hijacking or not?  What happens is a risk
> assessment of the login, is it from the usual location?  Usual country?
> Usual device type?  Is it from somewhere where you see a lot of unusual
> logins?  Does it look like some automated software and not a normal browser?
> How strong is the password?  How common is the password?

I don't think there is a reliable way to guess, based on a computed password
strength, how many blind attempts are necessary to crack it.  Even weak
passwords seem to resist quite well.  (Yet, bots keep trying...)


> Of course, if there's money to be made, there's a way, so you get people 
> stealing entire boxes of sim cards and creating special hardware to use
> them, see the pictures from this article:>
https://cyberpolice.gov.ua/news/kiberpolicziya-prypynyla-diyalnist-masshtabnogo-servisu-dlya-reyestracziyi-riznyx-akauntiv-u-mesendzherax-soczmerezhax-ta-poshtovyx-servisax-8596/


Some of those products seem to be true Apple ;-)


> This isn't about tracking, this is about keeping your data safe, and 
> protecting
> everyone else from


As if smartphone were the quintessential secure device.  That hype on using
smartphones for 2FA seems to be somewhat smelly to me.  Personally, I still use
a Nokia 2760, which I deem safer than Android.  Anyway, cell signal is poor in
my office so I really hate how everyone —especially banks— insist on SMS based
OTPs.  Perhaps, G5 will bring SMS via WiFi, but for the time being telephone
number is not an option for me.

In Italy we have a number of state-issued certificates, some on smart card
(identity card and health services card) and some just online (spid).  Last
month a minister suggested that they could be used also by others, such as
Google.  How controversial![*]  People reacted as if each use of the
certificate can be logged by its issuer.  By contrast, nobody notes that each
use of the smartphone /is/ logged by the telco provider.  Idiosyncratic, isn't 
it?


[*]
https://www.tellerreport.com/news/2020-01-04---controversy-explodes-on-state-user-and-password--pisano-specifies--%22spid-already-used-by-5-million%22-.r1fYeSH0yU.html


Best
Ale
-- 





























___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-27 Thread Jaroslaw Rafa via mailop 
Dnia 26.01.2020 o godz. 23:03:35 Brandon Long via mailop pisze:
> 
> Passwords are terrible and completely broken.   They are generally poorly
> chosen,
> weak, and re-used.  The result is extreme levels of hijacking.  On top of
> that, people
> forget their passwords and this isn't something like your home electricity
> bill or even
> your bank... how does Google know it's you?

If we are at this topic, I wonder since long time why none, literally none
publicly available Internet service where users' private data is stored and
needs to be protected, has implemented certificate-based login.

This is a solution that already exists for long time, is widely supported
in browsers, is secure - a perfect candidate for a second authentication
factor. Password (in service) + passphrase protecting the certificate +
certificate itself = isn't that secure enough? In my opinion it is. Yet
nobody is using this simple solution, instead we rely on some strange digit
codes sent via various side channels.

Brandon, can you perhaps explain how does it look from Google point of view?
Have you ever considered using certificates as a second authentication
factor, and if yes, why did you decide not to use them?
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-27 Thread Andrew C Aitchison via mailop 


That is pretty much what I thought, and I agree that this all is good to do.

I accept that in reality professional bad-guys are the biggest risk, but
in my paranoia I am more afraid of what happens if my phone slips out of
my pocket in a public place.
Assuming the person who picks it up can unlock my phone (that may be
unrealistic) if we have eliminated passwords then they have access
to all my data stored anywhere.

On Sun, 26 Jan 2020, Brandon Long wrote:


On Sun, Jan 26, 2020 at 10:35 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:

Hmm.
Proving that you can read a text sent to a number you provide today
does not prove that you are the person who used the ID and password
yesterday.
So they demand you provide a new verification channel so that you can
prove your ID *next* time ?

I find these multi-factor verifications unsettling because it takes
a significant effort to convince myself that the verification does
indeed prove what it is supposed to prove and that it is safe from
man-in-the-middle.  I have lost enough physical keys over the years
to worry about what happens if I lose my phone (which does not have
a finger print reader) ...


It's hard to determine what happened based on the descriptions, but
the general answer is pretty simple.

Passwords are terrible and completely broken.  They are generally
poorly chosen, weak, and re-used.  The result is extreme levels of
hijacking.  On top of that, people forget their passwords and this
isn't something like your home electricity bill or even your
bank... how does Google know it's you?

At the one end, that makes account recovery challenging, and it
certainly seems that Google decides that losing your account is
better than giving it to someone else.  There's probably extensive
arguments and concerns about how exactly the draw that line, but
that's the tension.  Your Google account can contain multitudes of
personal information, granting it to the wrong person can be
crippling to the main owner.  Losing access can also be terrible.

The other end of this, what do you do when someone presents the
right password to log in, is it a hijacking or not?  What happens is
a risk assessment of the login, is it from the usual location?
Usual country?  Usual device type?  Is it from somewhere where you
see a lot of unusual logins?  Does it look like some automated
software and not a normal browser?  How strong is the password?  How
common is the password?

The end result of that risk assessment is whether to let the user
in, or to make the login more complicated.  That started with
captchas, sometimes requiring up to 5 or more of them in the
riskiest case.  The next level is requiring a phone number.  Better
if the phone number used was already known to Google, but really any
phone number will do because a phone number costs money to obtain,
so limiting how many accounts can use a number or how frequently,
and you have raised the cost of accessing the account.  Of course,
then you need to know what all of the free or almost free phone
number services are, to not allow those to be used, as they don't
cost enough.

Of course, if there's money to be made, there's a way, so you get
people stealing entire boxes of sim cards and creating special
hardware to use them, see the pictures from this article:
https://cyberpolice.gov.ua/news/kiberpolicziya-prypynyla-diyalnist-masshtabnogo-servisu-dlya-reyestracziyi-riznyx-akauntiv-u-mesendzherax-soczmerezhax-ta-poshtovyx-servisax-8596/

This isn't about tracking, this is about keeping your data safe, and
protecting everyone else from what can be done with a hijacked
account, from sending spam to click fraud to YT abuse to bitcoin
mining on GCP.

In many respects, actually setting up 2FA on your account puts you
in a better situation.  It means that access to your account is hard
to abuse, and so the risk assessment is completely different.  Yes,
it means that you need to keep both the password and 2FA source
secure and available... but that's better than forcing Google to
guess at some secondary thing to verify you and choosing wrong.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-26 Thread Brandon Long via mailop 
On Sun, Jan 26, 2020 at 10:35 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:

> On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote:
>
> > Similar thing happened to me recently when I wanted to re-login to one of
> > those test accounts from my home computer, but I installed a new browser
> > which was not yet used with that account. Usually there are no problems
> in
> > such a case, but my home Internet connection just went down that day and
> I
> > had to switch to a backup connection via cellular modem. Probably because
> > of IP address belonging to a generally-accessible mobile operator's pool,
> > Google behaved differently when I logged in to the account. After I
> already
> > provided a correct password, Google demanded from me to enter a phone
> number
> > that can be used for verification (!) and I couldn't successfully
> complete
> > the login procedure, because I didn't want to associate any phone number
> > with that account.
>
> Hmm.
> Proving that you can read a text sent to a number you provide today
> does not prove that you are the person who used the ID and password
> yesterday.
> So they demand you provide a new verification channel so that you can
> prove your ID *next* time ?
>
> I find these multi-factor verifications unsettling because it takes
> a significant effort to convince myself that the verification does
> indeed prove what it is supposed to prove and that it is safe from
> man-in-the-middle.
> I have lost enough physical keys over the years to worry about what
> happens if I lose my phone (which does not have a finger print reader) ...
>

It's hard to determine what happened based on the descriptions, but the
general
answer is pretty simple.

Passwords are terrible and completely broken.   They are generally poorly
chosen,
weak, and re-used.  The result is extreme levels of hijacking.  On top of
that, people
forget their passwords and this isn't something like your home electricity
bill or even
your bank... how does Google know it's you?

At the one end, that makes account recovery challenging, and it certainly
seems that
Google decides that losing your account is better than giving it to someone
else.  There's
probably extensive arguments and concerns about how exactly the draw that
line, but that's
the tension.  Your Google account can contain multitudes of personal
information, granting it
to the wrong person can be crippling to the main owner.  Losing access can
also be terrible.

The other end of this, what do you do when someone presents the right
password to log in,
is it a hijacking or not?  What happens is a risk assessment of the login,
is it from the usual
location?  Usual country?  Usual device type?  Is it from somewhere where
you see a lot of
unusual logins?  Does it look like some automated software and not a normal
browser?  How
strong is the password?  How common is the password?

The end result of that risk assessment is whether to let the user in, or to
make the login more
complicated.  That started with captchas, sometimes requiring up to 5 or
more of them in the riskiest
case.  The next level is requiring a phone number.  Better if the phone
number used was already known
to Google, but really any phone number will do because a phone number costs
money to obtain, so
limiting how many accounts can use a number or how frequently, and you have
raised the cost of
accessing the account.  Of course, then you need to know what all of the
free or almost free phone
number services are, to not allow those to be used, as they don't cost
enough.

Of course, if there's money to be made, there's a way, so you get people
stealing entire boxes of sim
cards and creating special hardware to use them, see the pictures from this
article:
https://cyberpolice.gov.ua/news/kiberpolicziya-prypynyla-diyalnist-masshtabnogo-servisu-dlya-reyestracziyi-riznyx-akauntiv-u-mesendzherax-soczmerezhax-ta-poshtovyx-servisax-8596/

This isn't about tracking, this is about keeping your data safe, and
protecting everyone else from
what can be done with a hijacked account, from sending spam to click fraud
to YT abuse to bitcoin
mining on GCP.

In many respects, actually setting up 2FA on your account puts you in a
better situation.  It means that
access to your account is hard to abuse, and so the risk assessment is
completely different.  Yes, it
means that you need to keep both the password and 2FA source secure and
available... but that's
better than forcing Google to guess at some secondary thing to verify you
and choosing wrong.

Brandon
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-26 Thread John Levine via mailop 
In article <1580084583.939.2.ca...@16bits.net>,
Ángel via mailop  wrote:
>> I like TOTP codes because you can install the keys into multiple apps ...

>Not supported by Google, though.

The gmail app on my phone would be surprised to hear that, since I've
been logging in with TOTP codes for years.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-26 Thread John Levine via mailop 
In article ,
Andrew C Aitchison via mailop  wrote:
>I have lost enough physical keys over the years to worry about what
>happens if I lose my phone (which does not have a finger print reader) ...

I like TOTP codes because you can install the keys into multiple apps
on multiple devices, and since thes keys are just strings of letters
and digits, you can print the keys out and put the paper in a safe
place.


-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-26 Thread Raymond Burkholder via mailop 

On 2020-01-26 11:32 a.m., Andrew C Aitchison via mailop wrote:

On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote:

Similar thing happened to me recently when I wanted to re-login to 
one of

those test accounts from my home computer, but I installed a new browser
which was not yet used with that account. Usually there are no 
problems in
such a case, but my home Internet connection just went down that day 
and I
had to switch to a backup connection via cellular modem. Probably 
because
of IP address belonging to a generally-accessible mobile operator's 
pool,
Google behaved differently when I logged in to the account. After I 
already
provided a correct password, Google demanded from me to enter a phone 
number
that can be used for verification (!) and I couldn't successfully 
complete

the login procedure, because I didn't want to associate any phone number
with that account.


Hmm.
Proving that you can read a text sent to a number you provide today
does not prove that you are the person who used the ID and password 
yesterday.
So they demand you provide a new verification channel so that you can 
prove your ID *next* time ?


I find these multi-factor verifications unsettling because it takes
a significant effort to convince myself that the verification does
indeed prove what it is supposed to prove and that it is safe from 
man-in-the-middle.

I have lost enough physical keys over the years to worry about what
happens if I lose my phone (which does not have a finger print reader) .. 


I get the feeling this convoluted mechanism with no safe-guards or 
way-out is less about verification and much more about tracking.


Now I just wish there is a mechanism to just delete the account that I 
can no longer get into.  Now it is lost to la-la land.


I am who I am, and my email and authentication codes prove it.  Why the 
continuing demand for further verification which no longer exist?


Hidden in the recovery mechanism is a statement saying is that someone 
'may' look into it, given an email address.  Does that actually happen?  
Or is that just another add-on to their tracking toolings?


Frustrated with the inhuman machine,
Raymond.



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-26 Thread Andrew C Aitchison via mailop 

On Sun, 26 Jan 2020, Jaroslaw Rafa via mailop wrote:


Similar thing happened to me recently when I wanted to re-login to one of
those test accounts from my home computer, but I installed a new browser
which was not yet used with that account. Usually there are no problems in
such a case, but my home Internet connection just went down that day and I
had to switch to a backup connection via cellular modem. Probably because
of IP address belonging to a generally-accessible mobile operator's pool,
Google behaved differently when I logged in to the account. After I already
provided a correct password, Google demanded from me to enter a phone number
that can be used for verification (!) and I couldn't successfully complete
the login procedure, because I didn't want to associate any phone number
with that account.


Hmm.
Proving that you can read a text sent to a number you provide today
does not prove that you are the person who used the ID and password 
yesterday.
So they demand you provide a new verification channel so that you can 
prove your ID *next* time ?


I find these multi-factor verifications unsettling because it takes
a significant effort to convince myself that the verification does
indeed prove what it is supposed to prove and that it is safe from 
man-in-the-middle.

I have lost enough physical keys over the years to worry about what
happens if I lose my phone (which does not have a finger print reader) ...

--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-26 Thread Jaroslaw Rafa via mailop 
Dnia 26.01.2020 o godz. 02:30:57 Ángel via mailop pisze:
> The safest way to avoid this dance seems to be not to provide
> any phone at all (or one for every user, perhaps, which is also
> suboptimal).

Not providing a phone number at all also doesn't help sometimes.

As I have already written, when I had Gmail deliverability problems a few
months ago, I created a few Gmail acounts for test purposes. I usually was
able to create these accounts without providing any phone number, as long as
I was using my home Internet connection. But once I tried to create a new
Gmail account from my workplace and Google didn't allow me to create an
account without providing a phone number. And I have to admit, they are very
good at detecting and rejecting numbers from "scratch SMS" services
available on the web (similar to "temporary email", where you can receive a
confirmation code via text message without having a real phone number).
Probably it was because of the fact that there are thousands of Google
users connecting everyday from external IP addresses of my company (apart
from employees' personal Google accounts, our company also uses Gsuite, so
everybody logs in to their Gsuite account) and that's why they require the
additional phone check.

Similar thing happened to me recently when I wanted to re-login to one of
those test accounts from my home computer, but I installed a new browser
which was not yet used with that account. Usually there are no problems in
such a case, but my home Internet connection just went down that day and I
had to switch to a backup connection via cellular modem. Probably because
of IP address belonging to a generally-accessible mobile operator's pool,
Google behaved differently when I logged in to the account. After I already
provided a correct password, Google demanded from me to enter a phone number
that can be used for verification (!) and I couldn't successfully complete
the login procedure, because I didn't want to associate any phone number
with that account.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-25 Thread Ángel via mailop 
On 2020-01-23 at 11:44 -0700, Raymond Burkholder via mailop wrote:
> I went to log into Youtube, and Google says my device is unknown, and 
> wants to send a confirming text to a telephone number I no longer
> have.
> 
> The email confirmation methods all work, and validate my account.  Yet
> Google persists in requiring a confirmation of a no-longer owned phone
> number.

Ouch. That hurts.

Just to be clear: you do know your password, you just don't have the
same phone number (nor a logged in session).

Google is now very stubborn in requiring a phone-based confirmation.
I have seen that in the case of a shared mailbox, to which several users
have access to. The most prevalent user linked its phone, with the
result that other people is then barred from accessing it unless
authorized by the phone owner. :(
Also, since the account doesn't have 2FA enabled (albeit in practice it
acts as 2FA), it is not possible to create an App password.
Their steps make sense for a single user account, but breaks the flow
otherwise. The safest way to avoid this dance seems to be not to provide
any phone at all (or one for every user, perhaps, which is also
suboptimal).


In your case, you can probably get access again through the Account
recovery form: https://accounts.google.com/signin/recovery 

Provide the account password as the 'last password you remember', and
use the secondary mail they have on file for contact. A reason of 'I no
longer have this phone', for number they have not verificated in a long
time, on an account with no sign-ons either, with all that matching data
_should_ be crystal clear imho.


Good luck


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-24 Thread John Levine via mailop 
In article <20200123185907.ga4...@rafa.eu.org> you write:
>Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
>> At some point I give up and hit the spam button.
>
>And thus you are training Google's AI to treat completely legit (only
>misdirected) messages as spam.

If they keep sending me mail after I tell them to stop, how is that not spam?

R's,
John

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Hal Murray via mailop 

Michael Peddemors:
> Really wish there was a verifiable way to see that it was a 'Double  Optin/
> COI' email.. 

Has anybody investigated that area?

I think the recipient's ISP would have to get involved with the signup and 
unsubscribe process and keep track of which lists the user is signed up for.

I'm thinking of something like send the please-confirm message to 
signup@, the ISP would ask the user, if yes, send back a 
confirming message.  Maybe it should send back a cookie to be used as a header.

I see potential problems with users unsubscribing manually rather than using 
the unsubscribe button so their ISP knows they are no longer subscribed.


-- 
These are my opinions.  I hate spam.




___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread John R Levine via mailop 

message (this time to the correct address), it will end up in the
recipient's spam folder, without them knowing why.
Don't do it to them. Just delete those messages, don't put them to spam.


I disagree. If the sender wants eyeballs to see their emails, they need
some incentive to put in place the systems that'll validate the correct
recipients. Like double-opt-in. Especially before persistent and repeat
use of an address where you don't actually know the recipient wants your
mail.


In my experience the wrong-John mail consists of a great deal of 
individual and transaction mail and very little ordinary bulky stuff. 
These days most legit mailers have working unsubs so if someone signs me 
up, or more likely a store from which they've bought something assumes I 
want endless ads for stuff sort of like what I didn't buy, one click on 
the unsub button makes it stop.


Not so for wedding invitations, tax notices, and so forth.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Michael Ellis via mailop 
>> Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
>>> At some point I give up and hit the spam button.
>>
>> And thus you are training Google's AI to treat completely legit (only
>> misdirected) messages as spam.
>> Maybe one day these senders will find out that when they send another
>> message (this time to the correct address), it will end up in the
>> recipient's spam folder, without them knowing why.
>> Don't do it to them. Just delete those messages, don't put them to spam.
>
>
> I disagree. If the sender wants eyeballs to see their emails, they need
> some incentive to put in place the systems that'll validate the correct
> recipients. Like double-opt-in. Especially before persistent and repeat
> use of an address where you don't actually know the recipient wants your
> mail.
>
>

And when someone hits this is spam on a Double Optin/COI email?

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Mark Foster via mailop 
> Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
>> At some point I give up and hit the spam button.
>
> And thus you are training Google's AI to treat completely legit (only
> misdirected) messages as spam.
> Maybe one day these senders will find out that when they send another
> message (this time to the correct address), it will end up in the
> recipient's spam folder, without them knowing why.
> Don't do it to them. Just delete those messages, don't put them to spam.


I disagree. If the sender wants eyeballs to see their emails, they need
some incentive to put in place the systems that'll validate the correct
recipients. Like double-opt-in. Especially before persistent and repeat
use of an address where you don't actually know the recipient wants your
mail.




___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Michael Peddemors via mailop 
I often speak on this topic to ISP's, and I remind them, never argue 
with your customer on what is spam, and what isn't spam..


Sure, block/mark the 99% that is pretty obvious and fits everyone's 
definition of spam, by let your USERS decide on the fringe cases..


"If a message is in the spam folder, that the customer wants.. give them 
an allow sender button.. don't argue.. you just alienate the customers."


"If a message is in the inbox, and the customer doesn't want it, I don't 
care if it is from an ex-g/f, bill collector (or worse a lawyer *Teasing 
Anne*), let them click block sender"


Do your best, but empower the users .. Google had to learn that early, 
they didn't have a call center ;) But those methods we all can learn 
from, especially when the end user is paying the bills.


-- Michael --

PS, and of course, the more a customer can do, the more loyal they are 
in general..


On 2020-01-23 12:54 p.m., Jaroslaw Rafa via mailop wrote:

Dnia 23.01.2020 o godz. 19:28:03 Andrew Wingle via mailop pisze:


I can't recall the exact quote but a key rule is basically this;

"Spam is whatever my users say it is."
-Various Sources


Does work only when there is a small and somewhat homogenous community of
users, who have similar views about what is spam and what isn't.

With a mass provider like Google, when there are thousands, even millions of
users with completely different (and often opposite) expectations about what
they want to receive and what not, users who don't know each other, this
rule does not apply. If my decisions can influence mail reception for some
other person, completely unknown to me, who doesn't share my views about
what is spam, then something's wrong.





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Jaroslaw Rafa via mailop 
Dnia 23.01.2020 o godz. 13:39:33 Anne P. Mitchell, Esq. via mailop pisze:
> 
> > "Spam is whatever my users say it is."
> 
> And, delightfully, even CAN-SPAM says (essentially) that spam is whatever 
> ISPs say it is.

And I would agree with that. But i would treat the term "ISP" *very
strictly*. That is, some humans from ISP staff who are responsible for
imposing exact rules of spam classifications.

Not decisions of random users, not an uncontrollable AI with nobody having
an idea how it exactly operates.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Jaroslaw Rafa via mailop 
Dnia 23.01.2020 o godz. 19:28:03 Andrew Wingle via mailop pisze:
> 
> I can't recall the exact quote but a key rule is basically this;
> 
> "Spam is whatever my users say it is."
>   -Various Sources 

Does work only when there is a small and somewhat homogenous community of
users, who have similar views about what is spam and what isn't.

With a mass provider like Google, when there are thousands, even millions of
users with completely different (and often opposite) expectations about what
they want to receive and what not, users who don't know each other, this
rule does not apply. If my decisions can influence mail reception for some
other person, completely unknown to me, who doesn't share my views about
what is spam, then something's wrong.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Anne P. Mitchell, Esq. via mailop 


> I can't recall the exact quote but a key rule is basically this;
> 
> "Spam is whatever my users say it is."

And, delightfully, even CAN-SPAM says (essentially) that spam is whatever ISPs 
say it is.

Anne

---
Anne P. Mitchell, Attorney at Law, Dean of Cyberlaw, Lincoln Law School of San 
Jose
CEO/President, SuretyMail Email Reputation Certification
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant, GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Former Counsel: Mail Abuse Prevention System (MAPS)
Location: Boulder, Colorado



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Anne P. Mitchell, Esq. via mailop 

While most of the misdirected email I get is just a nuisance, just last week a 
lawyer at a law firm in California, with whom I have no connection, emailed 
documents in a case, with which I have no connection, to opposing counsel, with 
whom I have no connection (are you a detecting a theme here?) - only somehow 
they sent them to me instead of opposing counsel.  I say "somehow" because 
there is literally no connection at all - the fact that I am a lawyer was a 
coincidence, but a fun one, because I got to reply-all pointing out the error 
of their ways (and an egregious one at that). ;~)

Anne

Anne P. Mitchell, Attorney at Law, Dean of Cyberlaw, Lincoln Law School of San 
Jose
CEO/President, SuretyMail Email Reputation Certification
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant, GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Former Counsel: Mail Abuse Prevention System (MAPS)
Location: Boulder, Colorado


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Andrew Wingle via mailop 
> And thus you are training Google's AI to treat completely legit (only 
> misdirected) messages as spam.
> Don't do it to them. Just delete those messages, don't put them to spam.

I can't recall the exact quote but a key rule is basically this;

"Spam is whatever my users say it is."
-Various Sources 


Andrew Wingle

-Original Message-
From: mailop  On Behalf Of Jaroslaw Rafa via mailop
Sent: Thursday, January 23, 2020 1:59 PM
To: John Levine 
Cc: bl...@google.com; mailop@mailop.org
Subject: Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with 
List Washing services, industry feedback..

Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
> At some point I give up and hit the spam button.

And thus you are training Google's AI to treat completely legit (only
misdirected) messages as spam.
Maybe one day these senders will find out that when they send another message 
(this time to the correct address), it will end up in the recipient's spam 
folder, without them knowing why.
Don't do it to them. Just delete those messages, don't put them to spam.
--
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there was 
a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Jaroslaw Rafa via mailop 
Dnia 22.01.2020 o godz. 23:31:13 John Levine via mailop pisze:
> At some point I give up and hit the spam button.

And thus you are training Google's AI to treat completely legit (only
misdirected) messages as spam.
Maybe one day these senders will find out that when they send another
message (this time to the correct address), it will end up in the
recipient's spam folder, without them knowing why.
Don't do it to them. Just delete those messages, don't put them to spam.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Raymond Burkholder via mailop 

On 2020-01-23 11:17 a.m., Cal Frye via mailop wrote:
Once a gentleman on the west coast used my gmail address as his iTunes 
account email. Not sure what was in his head, but he insisted that would 
work just fine, and wouldn't fix it (for a couple of weeks). So I 
changed his iTunes password and locked his phone. Problem got resolved 
very quickly after that.


On an almost related tangent, I wish I could figure out how to deal with 
Google/Youtube.  I had not logged into Youtube in a long while (using 
this email address).  I moved, changed phone numbers, changed computers.


I went to log into Youtube, and Google says my device is unknown, and 
wants to send a confirming text to a telephone number I no longer have.


The email confirmation methods all work, and validate my account.  Yet 
Google persists in requiring a confirmation of a no-longer owned phone 
number.


As remediation, Google suggests that I might create a new account. Of 
what value is that, when all the content I uploaded is in my already 
existing account?


Is that a remnant of their 'tracking' or is that a plausible mechanism 
of protection?


There doesn't appear to be any alternate mechanism for accessing that 
account.




Cal Frye

John Levine via mailop wrote on 1/22/20 11:31 PM:
In article 
 
you write:

This type of thing is depressingly common for addresses that are common
names and such at the major providers. ...

No kidding.  You would not believe (well, you, Brandom sure would) how
many people with names similar to mine believe that my address
john.lev...@gmail.com is their address.  I get all sorts of rather
personal stuff, offers of work for a psychiatrist in Boston, wedding
invitations and tax documents for a druggist in Paris, car repair
appointments for a guy in Phoenix.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-23 Thread Cal Frye via mailop 
Once a gentleman on the west coast used my gmail address as his iTunes 
account email. Not sure what was in his head, but he insisted that would 
work just fine, and wouldn't fix it (for a couple of weeks). So I 
changed his iTunes password and locked his phone. Problem got resolved 
very quickly after that.


Cal Frye

John Levine via mailop wrote on 1/22/20 11:31 PM:

In article  
you write:

This type of thing is depressingly common for addresses that are common
names and such at the major providers. ...

No kidding.  You would not believe (well, you, Brandom sure would) how
many people with names similar to mine believe that my address
john.lev...@gmail.com is their address.  I get all sorts of rather
personal stuff, offers of work for a psychiatrist in Boston, wedding
invitations and tax documents for a druggist in Paris, car repair
appointments for a guy in Phoenix.



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [FEEDBACK] whose address, was Approach to dealing with List Washing services, industry feedback..

2020-01-22 Thread John Levine via mailop 
In article  
you write:
>This type of thing is depressingly common for addresses that are common
>names and such at the major providers. ...

No kidding.  You would not believe (well, you, Brandom sure would) how
many people with names similar to mine believe that my address
john.lev...@gmail.com is their address.  I get all sorts of rather
personal stuff, offers of work for a psychiatrist in Boston, wedding
invitations and tax documents for a druggist in Paris, car repair
appointments for a guy in Phoenix.

The worst of it is that when I tell people that I am not the person
they are looking for, half the time they do not believe me and insist
that I must be that guy, because if I'm not, why did I give them that
address.  In none of the cases have I been able to figure out what the
other people's actual addresses are, probably my name with a number,
but there are a lot of numbers.

At some point I give up and hit the spam button.

R's,
John



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop