61–66 of 66 posts
I feel like Google does this many times to hurt the competition.
What is "this" in this context? Scan websites for vulnerabilities? Make the results of automated vulnerability scans available?
Any URL shortening site that doesn't have an active block list is likely linking to some unsafe sites. Singling out bit.ly in this instance is frankly unfair. Guess who else Google warns is linking to unsafe sites: https://www.google.com/safebrowsing/diagnostic?site=google.c...
goo.gl too, with nearly 6,300 links to Trojans, way more than on the bit.ly report: https://www.google.com/safebrowsing/diagnostic?site=goo.gl
Earlier quoted context omitted.
Why would you use bit.ly links in email?
The sibling replies are mostly a load of bollocks. E-mail based publishers track clicks anyway through much better means, such as Mailchimp's click tracking - no reputable sender needs to use bit.ly to track stuff. The reason bit.ly links can end up in mails is if third parties want to track clicks separate from the sender and the sender isn't smart enough to catch it. For example, people who want to include a job li…
Earlier quoted context omitted.
They do. It is called IP reputation, and is the main reason your inbox is mostly spam-free: Google (and all the other large mail providers) keep reputation scores for IPs / IP blocks, based on what volume of ham/spam they send, and for the larger commercial senders they outsource anti-spam management by saying "Hey MSA: here are the minimum requirements for email getting relayed to Google customers. Ensure your custo…
> They do. It is called IP reputation I didn't say Google has no way of detecting spam - I said Google doesn't know the recipients " double opted in and want to receive the mail "
How does Google know you're clean on permission if you are coming from a MailChimp IP? Because Google knows MailChimp knows what Google will do to MailChimp if you aren't innocent.
Earlier quoted context omitted.
The sibling replies are mostly a load of bollocks. E-mail based publishers track clicks anyway through much better means, such as Mailchimp's click tracking - no reputable sender needs to use bit.ly to track stuff. The reason bit.ly links can end up in mails is if third parties want to track clicks separate from the sender and the sender isn't smart enough to catch it. For example, people who want to include a job li…
Above you said that you didn't sent spam because your recipients opted in. OK. Now you say that these email newsletters contain third-party advertising. You're sending paid advertising in an email. I would consider that to be spam, even if I opted in to your newsletter. I accept the fact that not everyone would define it that way, but I hope you see my point.
* law (e.g. CAN-SPAM or the Privacy and Electronic Communications Regulations 2003) - indeed CAN-SPAM even stands for Controlling the Assault of Non-Solicited Pornography And Marketing Act and reflects the US government's position, the EU's regulations refer to 'unsolicited communications' - http://www.legislation.gov.uk/uksi/2003/2426/regulation/22/m...
* encyclopedia (say, Wikipedia - http://en.wikipedia.org/wiki/Spamming - or the Encyclopedia Britannica - http://www.britannica.com/EBchecked/topic/941678/spam)
* dictionaries (say, Websters - http://www.merriam-webster.com/dictionary/spam - or the Oxford - http://www.oxforddictionaries.com/definition/english/spam)
* technical standards (say, RFC2505 - http://tools.ietf.org/html/rfc2505)
* the viewpoint of people extremely against spam, such as Spamhaus - http://www.spamhaus.org/consumer/definition/ or SpamCop - http://www.spamcop.net/fom-serve/cache/14.html
* the terms and conditions of e-mail service providers and senders - e.g. http://mailchimp.com/legal/terms/
Earlier quoted context omitted.
Ummm... Html5 audio/video api works just fine on chrome mobile. IOS safari is the bad actor, there ;)
Ummm..., no? In Chrome mobile you can only do for example .play() on an audio or video element, if you call it from an eventListener that reacted to an onClick event.
iOS on the other hand actually -does- initiate bandwidth use on a element, even if no interaction has taken place. If you watch Charles during an iOS video session, you will see 2-3 HTTP GETs before you even initiate playback. This can play merry hell if with your HTTP logs, if you pay attention to that sort of thing.
iOS also has major issues with multiple elements; must be full-screen on non-tablet i-devices (you cannot create custom controls); you cannot control volume via the user interface; it uses a nonstandard progression for its status-related events... (and sometimes they're just plain missing)...
I've spent the past few years working on web media players for mobile and desktop ;) I kind of know what I'm talking about. And due to its position in the marketplace, iOS Safari has stagnated - it's easier to get HTML5 multimedia working correctly in IE11 than iOS Safari. iOS Safari is the new IE6.