You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "@lbutlr" <kr...@kreme.com> on 2018/04/01 20:46:35 UTC
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
On 2018-02-20 (08:30 MST), Rob McEwen <ro...@invaluement.com> wrote:
>
> RE: The "goo.gl
> " shortner is OUT OF CONTROL (+ invaluement's response)
<https://tidbits.com/2018/04/01/google-sunsets-goo-gl-url-shortener/>
--
Technically, Aziraphale was a Principality, but people made jokes about
that these days
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
>
> > >
> > > "IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies
> > > require contribution. Please contact us informing your IP or range, for
> > > further details."
> >
> > This means, for example, your system do 10 queries at same second, then
> the
> > query frequency is 100ms.
>
> Yes, I got that bit.
>
> How big is an IP block?
>
Maybe I did not understand your question, but our DNSBL lists individual
IPs, even /128 for IPv6.
Sometimes our system lists entire blocks, like /64 for IPv6 and /24 for
IPv4.
>
> > > Please could you explain what this means; what limitations are imposed
> on
> > > use of this service - specifically what is an "IP block", and do you
> really
> > > mean "lower frequencies require contribution"? Surely that should be
> > > "higher"?
> >
> > Yes, I am sure. Lets use the same example above, but now your system do
> 20
> > queries at same second, then the query frequency becomes 50ms, less than
> > first case.
>
> Ah; I would call 50ms the interval and 20 queries per second the frequency.
>
> Thanks for the explanation.
>
>
You are always welcome!
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Antony Stone <An...@spamassassin.open.source.it>.
On Tuesday 03 April 2018 at 16:09:38, Leandro wrote:
> 2018-04-03 10:34 GMT-03:00 Antony Stone:
> > On Tuesday 03 April 2018 at 15:27:11, Leandro wrote:
> > > Hey guys. We just created an URL signature algorithm to be able to
> > > query an entire URL at our URIBL:
> > >
> > > https://spfbl.net/en/uribl/
> >
> > I don't think I understand the following statement on that page:
> >
> > "IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies
> > require contribution. Please contact us informing your IP or range, for
> > further details."
>
> This means, for example, your system do 10 queries at same second, then the
> query frequency is 100ms.
Yes, I got that bit.
How big is an IP block?
> > Please could you explain what this means; what limitations are imposed on
> > use of this service - specifically what is an "IP block", and do you really
> > mean "lower frequencies require contribution"? Surely that should be
> > "higher"?
>
> Yes, I am sure. Lets use the same example above, but now your system do 20
> queries at same second, then the query frequency becomes 50ms, less than
> first case.
Ah; I would call 50ms the interval and 20 queries per second the frequency.
Thanks for the explanation.
Antony.
--
90% of networking problems are routing problems.
9 of the remaining 10% are routing problems in the other direction.
The remaining 1% might be something else, but check the routing anyway.
Please reply to the list;
please *don't* CC me.
Re: OT: Frequency vs. Period (was Re: The "goo.gl" shortner...)
Posted by Leandro <le...@spfbl.net>.
2018-04-03 11:57 GMT-03:00 Dianne Skoll <df...@roaringpenguin.com>:
> On Tue, 3 Apr 2018 11:09:38 -0300
> Leandro <le...@spfbl.net> wrote:
>
> > This means, for example, your system do 10 queries at same second,
> > then the query frequency is 100ms.
>
> In SI units, frequency has the unit s^(-1) and period has the unit s,
> where s stands for "second"
>
> So 100ms is the period, and 10/s is the frequency. Basic dimensional
> analysis.
>
You are right! My mistake. I just fixed website information. Thanks!
>
> Regards,
>
> Dianne.
>
Re: OT: Frequency vs. Period (was Re: The "goo.gl" shortner...)
Posted by "Kevin A. McGrail" <km...@apache.org>.
Note: Goo.gl is being shutdown.
https://www.engadget.com/2018/03/30/google-shutting-down-goo-gl-url-shortening-service/
Apologies if I already noted that here.
--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Tue, Apr 3, 2018 at 10:57 AM, Dianne Skoll <df...@roaringpenguin.com>
wrote:
> On Tue, 3 Apr 2018 11:09:38 -0300
> Leandro <le...@spfbl.net> wrote:
>
> > This means, for example, your system do 10 queries at same second,
> > then the query frequency is 100ms.
>
> In SI units, frequency has the unit s^(-1) and period has the unit s,
> where s stands for "second"
>
> So 100ms is the period, and 10/s is the frequency. Basic dimensional
> analysis.
>
> Regards,
>
> Dianne.
>
OT: Frequency vs. Period (was Re: The "goo.gl" shortner...)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 3 Apr 2018 11:09:38 -0300
Leandro <le...@spfbl.net> wrote:
> This means, for example, your system do 10 queries at same second,
> then the query frequency is 100ms.
In SI units, frequency has the unit s^(-1) and period has the unit s,
where s stands for "second"
So 100ms is the period, and 10/s is the frequency. Basic dimensional
analysis.
Regards,
Dianne.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
>
> > > Then the frequency is 10 per second, not 100ms. Querying more often
> > > is a higher frequency.
> >
> > That is it! 10 per second or one every 100ms. The first is a flow rate
> and
> > the second is a frequency.
>
> One every 100ms is a frequency, agreed.
>
> Two every 100ms is a higher frequency, and means faster requests.
>
> One every 50ms is the same rate as two every 100ms, therefore it is also a
> higher frequency than one every 100ms.
>
You are right! My mistake. I just fixed website information. Thanks!
>
> Regards,
>
>
> Antony.
>
> --
> I wasn't sure about having a beard at first, but then it grew on me.
>
>
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Antony Stone <An...@spamassassin.open.source.it>.
On Tuesday 03 April 2018 at 16:43:09, Leandro wrote:
> 2018-04-03 11:35 GMT-03:00 RW:
> > On Tue, 3 Apr 2018 11:09:38 -0300 Leandro wrote:
> > > 2018-04-03 10:34 GMT-03:00 Antony Stone:
> > > > "IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies
> > > > require contribution. Please contact us informing your IP or range,
> > > > for further details."
> > >
> > > This means, for example, your system do 10 queries at same second,
> > > then the query frequency is 100ms.
> >
> > Then the frequency is 10 per second, not 100ms. Querying more often
> > is a higher frequency.
>
> That is it! 10 per second or one every 100ms. The first is a flow rate and
> the second is a frequency.
One every 100ms is a frequency, agreed.
Two every 100ms is a higher frequency, and means faster requests.
One every 50ms is the same rate as two every 100ms, therefore it is also a
higher frequency than one every 100ms.
Regards,
Antony.
--
I wasn't sure about having a beard at first, but then it grew on me.
Please reply to the list;
please *don't* CC me.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
2018-04-03 11:35 GMT-03:00 RW <rw...@googlemail.com>:
> On Tue, 3 Apr 2018 11:09:38 -0300
> Leandro wrote:
>
> > 2018-04-03 10:34 GMT-03:00 Antony Stone <
> > Antony.Stone@spamassassin.open.source.it>:
>
> > > "IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies
> > > require contribution. Please contact us informing your IP or range,
> > > for further details."
> > >
> >
> >
> > This means, for example, your system do 10 queries at same second,
> > then the query frequency is 100ms.
>
> Then the frequency is 10 per second, not 100ms. Querying more often
> is a higher frequency.
>
That is it! 10 per second or one every 100ms. The first is a flow rate and
the second is a frequency.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by RW <rw...@googlemail.com>.
On Tue, 3 Apr 2018 11:09:38 -0300
Leandro wrote:
> 2018-04-03 10:34 GMT-03:00 Antony Stone <
> Antony.Stone@spamassassin.open.source.it>:
> > "IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies
> > require contribution. Please contact us informing your IP or range,
> > for further details."
> >
>
>
> This means, for example, your system do 10 queries at same second,
> then the query frequency is 100ms.
Then the frequency is 10 per second, not 100ms. Querying more often
is a higher frequency.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
2018-04-03 10:34 GMT-03:00 Antony Stone <
Antony.Stone@spamassassin.open.source.it>:
> On Tuesday 03 April 2018 at 15:27:11, Leandro wrote:
>
> > Hey guys. We just created an URL signature algorithm to be able to query
> an
> > entire URL at our URIBL:
> >
> > https://spfbl.net/en/uribl/
>
> I don't think I understand the following statement on that page:
>
> "IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies require
> contribution. Please contact us informing your IP or range, for further
> details."
>
This means, for example, your system do 10 queries at same second, then the
query frequency is 100ms.
>
> Please could you explain what this means; what limitations are imposed on
> use
> of this service - specifically what is an "IP block", and do you really
> mean
> "lower frequencies require contribution"? Surely that should be "higher"?
>
Yes, I am sure. Lets use the same example above, but now your system do 20
queries at same second, then the query frequency becomes 50ms, less than
first case.
>
>
> Thanks,
>
>
> Antony.
>
> --
> There's a good theatrical performance about puns on in the West End. It's
> a
> play on words.
>
> Please reply to the
> list;
> please *don't* CC
> me.
>
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Antony Stone <An...@spamassassin.open.source.it>.
On Tuesday 03 April 2018 at 15:27:11, Leandro wrote:
> Hey guys. We just created an URL signature algorithm to be able to query an
> entire URL at our URIBL:
>
> https://spfbl.net/en/uribl/
I don't think I understand the following statement on that page:
"IMPORTANT: Current limit is 100 ms per IP block. Lower frequencies require
contribution. Please contact us informing your IP or range, for further
details."
Please could you explain what this means; what limitations are imposed on use
of this service - specifically what is an "IP block", and do you really mean
"lower frequencies require contribution"? Surely that should be "higher"?
Thanks,
Antony.
--
There's a good theatrical performance about puns on in the West End. It's a
play on words.
Please reply to the list;
please *don't* CC me.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
>
> We just created an URL signature algorithm to be able to query an entire
> URL at our URIBL:
>
> https://spfbl.net/en/uribl/
>
> Now we are able to blacklist any malicious shortener URL
>
>
> Leandro,
>
> Thanks for all you do! And good luck with that. But there are a few
> potential problems. When I analyzed Google's shortners about a month ago, I
> found that a VERY large percentage of the most malicious shortened URLs
> were a situation where the spammers were generating a unique shortner for
> each individual message/recipient-address. This causes the following HUGE
> problems (at least for THESE particular shortners) when publishing a
> full-URL dnsbl:
>
Thank you for all those observations!
> (1) much of what you populate your rbldnsd file with is going to be
> totally ineffective for anyone since it ONLY applied to whatever single
> email address where the spam was original sent (where you had trapped it) -
> everyone else is going to get DIFFERENT shortners for the spam from these
> same campaigns that are sent to their users.
>
You are right, but we do not use rbldnsd. We have our own DNSBL
implementation that uses a more efficient data structure. Anyway, I thing
that is not a good idea list each shortener, as you sad. Maybe thrice
complains of same shortener. We will discover what is the best some time.
> (2) get ready for EXTREME rbldnsd bloat. You're gonna need a LOT of RAM
> eventually? And if you ever distribute via rsync, those are going to be
> HUGE rsync files (and then THEY will need a lot of RAM). Sadly, most of
> that bloat is going to come from entries that are doing absolutely nothing
> for anyone.
>
That is it! We use a VM with 16GB and the software is using about 10GB to
keep more than 30 million registers at memory. That is something about 350
bytes per register. Our software have an expiration mechanism, than this
memory occupation is not growing to fast now. But we must keep one eye on
it always.
> (3) You might be revealing your spam traps to the spammers. In cases where
> the spammers are sending that 1-to-1 spam to single recipient shortners,
> then all they gave to do is enumerate through their list of shortners,
> checking them against your list - and they INSTANTLY get a list of every
> recipient address that triggers a listing on your DNSBL. If you want to
> destroy the effectiveness of your own DNSBL's spam traps - be my guest. But
> if you're getting 3rd party spam feeds (paid or free) - then know that
> you're then screwing over your 3rd party spam feed's spam traps - and those
> OTHER anti-spam system that rely on such feeds, which will then diminish in
> quality. (unless you are filtering OUT these MANY 1-to-1 shortner spams)
>
Not only spamtraps will trigger this listing. All active users will do it
too by complains. The spammer will not know who is spamtrap and who is
active user.
> Maybe there is enough OTHER shortners (that are sending the same shortners
> to multiple recipients) to make this worthwhile? But the bloat from the
> ones that are uniquely generated could be a challenge, and could
> potentially cause a MASSIVE amount of useless queries. I'd be very
> interested to see what PERCENTAGE of such queries generated a hit!
>
> Meanwhile, in my analysis I did about a month ago, about 80% of Google's
> shortners found in egregious spams (that did this one-to-one
> shorter-to-recipient tactic)... were all banging on one of ONLY a dozen
> different spammers' domains. Therefore, doing a lookup on these and then
> checking the domain found at the base of the link it redirects to... is a
> more effective strategy for these - whereas, for THESE 80% of egregious
> google shortners, a full URL lookup is worthless, consuming resources
> without a single hit.
>
That is right. We have same situation here.
But check first URL is not only action we do. Our script can follow
shortener redirections and catch the spammer by last URL of redirection
chain:
https://www.dropbox.com/s/5aorrijafw5ygk0/uribl.pl?dl=0
The spammers can be trapped by any shortener they have or by this dozen
domains that shortener hides.
Alternatively, you may have found a way to filter out these types of
> individualized shortners, to prevent that bloat? But even then, everyone
> should know that while your new list might be helpful, it would be good for
> others to know your new list isn't applicable to a large percentage of
> spammy shortners, since it is still useless against these individualized
> shortners.
>
I think that we all must cause to much of work for spammers, as much they
cause to us. If the spammer uses individualized shorteners, we can list
each one by crossing data with listed final chain URL domains. If they uses
individualized URL domains, we can list each one by crossing data with
listed URL equivalent IP (same machine for all spammer domains). We can
make it more and more expensive for spammers. But we must work together to
do it.
> NOTE: Google has made some improvements recently, and I haven't yet
> analyzed how much those improvements have changed any of these things I've
> mentioned?
>
> PS - the alphanumeric code at the end of these shortners tend to be
> case-sensitive, while the rest of the URL is NOT case sensitive (and they
> also work with both "https" and "http")... so you might want to standardize
> this on (1) https and (2) everything lower case up until the code at the
> end of the shortner - before the MD5 is calculated. Otherwise, it could
> easily break if the spammer just mixes up the capitalization of the
> shortner URL up until the code at the end of the shortner.
>
Great! I did not thought this. This is a new problem and your solution is
very good. Let's discuss more about this idea before any implementation.
> --
> Rob McEwenhttps://www.invaluement.com
>
>
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Tue, 3 Apr 2018 11:21:35 -0400
Rob McEwen <ro...@invaluement.com> wrote:
> Thanks for all you do! And good luck with that. But there are a few
> potential problems. When I analyzed Google's shortners about a month
> ago, I found that a VERY large percentage of the most malicious
> shortened URLs were a situation where the spammers were generating a
> unique shortner for each individual message/recipient-address.
We found that too, but in most cases, they generated the unique URLs
by adding query parameters to the same base URL, sort of like this:
http://malware.net/?id=znsjdsjau
http://malware.net/?id=aosu94e
etc...
and then shortening them.
So if you blacklist just the base URL, you cover those all off,
assuming you expand out shortened URLs as part of your processing, of course.
> Meanwhile, in my analysis I did about a month ago, about 80% of
> Google's shortners found in egregious spams (that did this one-to-one
> shorter-to-recipient tactic)... were all banging on one of ONLY a
> dozen different spammers' domains. Therefore, doing a lookup on these
> and then checking the domain found at the base of the link it
> redirects to... is a more effective strategy for these - whereas, for
> THESE 80% of egregious google shortners, a full URL lookup is
> worthless, consuming resources without a single hit.
Yep, that's what we found too.
Regards,
Dianne.
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Rob McEwen <ro...@invaluement.com>.
On 4/3/2018 9:27 AM, Leandro wrote:
> We just created an URL signature algorithm to be able to query an
> entire URL at our URIBL:
>
> https://spfbl.net/en/uribl/
>
> Now we are able to blacklist any malicious shortener URL
Leandro,
Thanks for all you do! And good luck with that. But there are a few
potential problems. When I analyzed Google's shortners about a month
ago, I found that a VERY large percentage of the most malicious
shortened URLs were a situation where the spammers were generating a
unique shortner for each individual message/recipient-address. This
causes the following HUGE problems (at least for THESE particular
shortners) when publishing a full-URL dnsbl:
(1) much of what you populate your rbldnsd file with is going to be
totally ineffective for anyone since it ONLY applied to whatever single
email address where the spam was original sent (where you had trapped
it) - everyone else is going to get DIFFERENT shortners for the spam
from these same campaigns that are sent to their users.
(2) get ready for EXTREME rbldnsd bloat. You're gonna need a LOT of RAM
eventually? And if you ever distribute via rsync, those are going to be
HUGE rsync files (and then THEY will need a lot of RAM). Sadly, most of
that bloat is going to come from entries that are doing absolutely
nothing for anyone.
(3) You might be revealing your spam traps to the spammers. In cases
where the spammers are sending that 1-to-1 spam to single recipient
shortners, then all they gave to do is enumerate through their list of
shortners, checking them against your list - and they INSTANTLY get a
list of every recipient address that triggers a listing on your DNSBL.
If you want to destroy the effectiveness of your own DNSBL's spam traps
- be my guest. But if you're getting 3rd party spam feeds (paid or free)
- then know that you're then screwing over your 3rd party spam feed's
spam traps - and those OTHER anti-spam system that rely on such feeds,
which will then diminish in quality. (unless you are filtering OUT these
MANY 1-to-1 shortner spams)
Maybe there is enough OTHER shortners (that are sending the same
shortners to multiple recipients) to make this worthwhile? But the bloat
from the ones that are uniquely generated could be a challenge, and
could potentially cause a MASSIVE amount of useless queries. I'd be very
interested to see what PERCENTAGE of such queries generated a hit!
Meanwhile, in my analysis I did about a month ago, about 80% of Google's
shortners found in egregious spams (that did this one-to-one
shorter-to-recipient tactic)... were all banging on one of ONLY a dozen
different spammers' domains. Therefore, doing a lookup on these and then
checking the domain found at the base of the link it redirects to... is
a more effective strategy for these - whereas, for THESE 80% of
egregious google shortners, a full URL lookup is worthless, consuming
resources without a single hit.
Alternatively, you may have found a way to filter out these types of
individualized shortners, to prevent that bloat? But even then, everyone
should know that while your new list might be helpful, it would be good
for others to know your new list isn't applicable to a large percentage
of spammy shortners, since it is still useless against these
individualized shortners.
NOTE: Google has made some improvements recently, and I haven't yet
analyzed how much those improvements have changed any of these things
I've mentioned?
PS - the alphanumeric code at the end of these shortners tend to be
case-sensitive, while the rest of the URL is NOT case sensitive (and
they also work with both "https" and "http")... so you might want to
standardize this on (1) https and (2) everything lower case up until the
code at the end of the shortner - before the MD5 is calculated.
Otherwise, it could easily break if the spammer just mixes up the
capitalization of the shortner URL up until the code at the end of the
shortner.
--
Rob McEwen
https://www.invaluement.com
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
2018-04-03 10:27 GMT-03:00 Leandro <le...@spfbl.net>:
> Hey guys. We just created an URL signature algorithm to be able to query
> an entire URL at our URIBL:
>
> https://spfbl.net/en/uribl/
>
> Now we are able to blacklist any malicious shortener URL. Now I will think
> about some public complain interface that automatic lists any correct
> malicious sample using some simple AI.
>
Hi. I just implemented automatic URL listing for these criteria:
1. Shortener URL that redirect to other shortener (evasion) and
2. Shortener URL that redirect to a bad reputation URL domain (hiding).
The shortener URL will be automatically listed if queried at this tool:
https://matrix.spfbl.net/en/
I ask that you guys test this new feature and call me if any bug was found.
I will think at another objective criteria to add at this interface, for
automatic URL listings. Maybe you can help me think at one.
The goal of this feature is never depend on a human to check these URLs
listings, if possible, and be an alternative for services like Phishtank
and others.
To have a very fast abusive URL listings and quick public exposure of
malicious URLs.
>
> All you have to do now is implement a SA plugin to make this signature and
> do the URIBL query.
>
If anyone can do it. I will be very grateful!
>
> Regards,
>
> Leandro
> SPFBL.net
>
>
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by Leandro <le...@spfbl.net>.
Hey guys. We just created an URL signature algorithm to be able to query an
entire URL at our URIBL:
https://spfbl.net/en/uribl/
Now we are able to blacklist any malicious shortener URL. Now I will think
about some public complain interface that automatic lists any correct
malicious sample using some simple AI.
All you have to do now is implement a SA plugin to make this signature and
do the URIBL query.
Regards,
Leandro
SPFBL.net
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Rob McEwen <ro...@invaluement.com>.
On 4/1/2018 7:10 PM, Kevin A. McGrail wrote:
> No, I don't think it's an April Fool's trick though it is possible.
> They announced this a day or 2 ago.
> See
> https://www.cloudconnectcommunity.com/ccc/ls/community/g-suite-feature-ideas/post/6320666165116928
> and https://firebase.google.com/docs/dynamic-links/
I have been in talks with Google about this, sharing with them specific
data and stats. My contact there sent me an email about this a day or
two ago referencing that announcement - I just hadn't had time to review
it yet. So this is for real.
The data I had compiled and shared with them that I gathered about a
month ago... was devastating. I can't make that report public because
the spammers were OFTEN sending a one-to-one ratio of a single
individual google shortener per recipient address. Therefore, making
that data public would have revealed many spamtrap addresses (both mine
and those of 3rd party spam feeds). Another problem with that data... is
that I was finding 10s of thousands of google shortners that were
banging on the same dozens spammer's domains - and it would be so
trivial for Google to look for that pattern and then just wipe out all
of THOSE many shortners that were redirecting to one of these dozen
spammers' domains. At the same time, the vast majority of these
shortners were persisting for weeks and weeks with no sign that Google
was hardly lifting a finger to terminate them. In fact, in that initial
report, 95+% of shortners used by spammers were persisting for weeks on
end, and 80% of those were using one of those 12 spammer' domains.
HOWEVER... I started compiling new data few days ago, and it looks MUCH
better now. I'm not done putting that report together, but early
indications show that something has recently changed for the better -
but that there is still significant room for improvement, but they are
at least headed in the right direction. But that report is still under
construction.
So I think the pressure on Google, along with some of the data I
provided them... might have helped? Or maybe that was just "one straw
that broke the camel's back"? Either way, I'm happy that this seems to
be getting fixed, or they are at least headed in the right direction.
--
Rob McEwen
https://www.invaluement.com
+1 (478) 475-9032
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)
Posted by "Kevin A. McGrail" <km...@apache.org>.
No, I don't think it's an April Fool's trick though it is possible. They
announced this a day or 2 ago.
See
https://www.cloudconnectcommunity.com/ccc/ls/community/g-suite-feature-ideas/post/6320666165116928
and https://firebase.google.com/docs/dynamic-links/
Regards,
KAM
--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171
On Sun, Apr 1, 2018 at 5:02 PM, Benny Pedersen <me...@junc.eu> wrote:
> @lbutlr skrev den 2018-04-01 22:46:
>
>> On 2018-02-20 (08:30 MST), Rob McEwen <ro...@invaluement.com> wrote:
>>
>>>
>>> RE: The "goo.gl
>>> " shortner is OUT OF CONTROL (+ invaluement's response)
>>>
>>
>> <https://tidbits.com/2018/04/01/google-sunsets-goo-gl-url-shortener/>
>>
>
> april fools day :=)
>
Re: The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's
response)
Posted by Benny Pedersen <me...@junc.eu>.
@lbutlr skrev den 2018-04-01 22:46:
> On 2018-02-20 (08:30 MST), Rob McEwen <ro...@invaluement.com> wrote:
>>
>> RE: The "goo.gl
>> " shortner is OUT OF CONTROL (+ invaluement's response)
>
> <https://tidbits.com/2018/04/01/google-sunsets-goo-gl-url-shortener/>
april fools day :=)