Joel explains how a new monopoly will emerge around AJAX - <AUTHOR> http://joelonsoftware.com/items/2007/09/18.html

<comment><USER2> A couple of problems with his argument:

1) Web entrepreneurs working now still need to optimize for speed. It's not like the desktop world where you are launching a year or two from now and can wait for the computers to catch up. You are launching a month from now and it needs to be fast. I would prefer to use a web mail client other than GMail, simply because I'm scared of my Google dependency. But every other web email client I've used ( Yahoo, Joyent, inbox.com, Zimbra) feels much slower. Google spends enormous effort optimizing their javascript load times and it really pays off.

2) Broadband speeds are not growing at Moore's law. Terrible regulatory law trumps technological gains.

3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable.

4) The trouble with javascript is not cross browser incompatibility. If you use a good library and have learned common gotchas you should not have to spend too much time debugging IE ( I probably spend less than 10% of my javascript coding time on cross browser issues). The trouble with javascript is that there are still a number of things it just can't do, and won't be able to do until the browsers change. For instance, there is no way to detect the exact pixel size of a character of text. This makes it impossible to build a real word processor in javascript. Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games). Well ... it's almost impossible to do these things. I suppose you could define your own image and font formats completely in javascript, and render the entire screen using 1 pixel divs. But that's just crazy talk. It would be a huge library - maybe 250 MB - and would be very slow until computers got faster. And it would require eating at least 6000 packages of ramen to build the thing. Hmmmmm .... maybe I have an idea I can apply to YCombinator with ... :-)

<comment><USER3> _"... 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable...."_

I hazard a guess that the real value is not (just) in the _generated source code_ in the design tools - site used to generate the end result?

</comment></comment><comment><USER4> He has some interesting ideas and analogies, but it's not clear that Joel actually understands AJAX/JS. The browser incompatibility problems are largely overblown, and the most annoying limitations are imposed by the browser (meaning that no JS library is going to fix them). He also doesn't seem to realize that all of the Google JS running in his browser IS generated by a compiler (from JS in most cases, from Java in a few others).

<comment><USER5> Agreed. Joel is growing old :-) He is young enough to keep up with major valley developments (Twitter and YComb) but too old to have a grasp on technical details (Java-to-JS-compilers, for instance).

Another thing he is wrong about is "moore law of bandwidth": it does not exist. While CPUs are getting faster and RAM is growing like crazy, bandwidth is not growing. In fact I am starting to notice an annoying trend of businesses running on slower and slower connections.

But his thoughts on parallels between terminal/HTML transition to Windows/FancySDK are cool nevertheless. He may not be right about everything, but something _similar_ to what he's talking about sure will happen.

Steve Yeggie blogged about inevitable "Rails for the Client" some time ago. Similar idea but expressed in more technical terms.

<comment><USER6> "...but too old to have a grasp on technical details..."

Huh? Am I the only one the notice how illogical this is?

We are not basketball players. Some of us do are best hacking in our 40's and 50's. (Lay off the drugs - you'll see.)

Joel has forgotten more than many here have ever known about hacking. His only problem with this essay is that he has the balls to make a prediction.

There is only one prediction that is always 100% accurate - that no prediction will ever be 100% accurate.

Great read, Joel. Now back to my ramen.

<comment><USER5> Dude, I've been reading Joel since 2002, and every time he goes on to blog about hacking he looks silly. His posts about "harm of exceptions" (he prefers -1 as a return code), about "mistake of .NET" and, from relatively recent ones, about poor Ruby performance do not make him look good as a hacker in my opinion.

Besides, he never really was a programmer. If I remember correctly he started his career as a program manager at Microsoft.

He's great as a general technology trends observer and I find his thoughts on business side of software crafting immensely useful, bug a hacker? No.

<comment><USER7> > His posts about "harm of exceptions"

So am I officially the only person who agrees with Joel on this?

</comment></comment></comment></comment></comment><comment><USER3> _"... Not just cut 'n' paste: cool mashup features like synchronization and single-point identity management (so you don't have to tell Facebook and Twitter what you're doing, you can just enter it in one place) ..."_

I've been doing something similiar to this. Here's what I'm finding working with lots of different 3rd party sites ...

Using API's

\- not every site has an API or RSS so you have to CUT+PASTE :(

\- even sites with API's have poor documentation (code, txt) so it can be difficult to use

\- posting data (say to twitter,flickr ) is way easier than extracting via an API/RSS

\- no company(ies) want(s) their hard-won user data to be used commercially (check the legal agreements) so while you can integrate each site requires permission - yuk!

\- solve the password & authorisation problem for each 3rd party site

Integration layer

\- abstract an API to talk to each service (eg: as Perl does to databases in the DBI module)

\- support the most popular sites that people use first (flickr, twitter, Facebook, MySpace etc)

\- constrain the features you want to support for each 3rd party site (eg: notifications by friends in twitter, or flickr. New books suggested in <http://www.librarything.com>)

\- keep up with changes made to each service, handle bugs, quirky code

Extraction layer

\- synchronise 3rd party added data and client side added data (the "add in 1 place" bit mentioned). This means being able to either/or add data at the client or get the data the user added at the 3rd party site as well and somehow sychronise them

\- you need tools to extract, manipulate RSS/ATOM feeds. A boon because you don't need API's

Messaging layer

\- using your abstracted API be able to message various different services and here's the hard bit depending on the service. Do you want to send everyone on Twitter a photo update if you have entered 20 flickr photos?

\- you need to capture store, query, link check and update the various links, metadata and information that message generates.

Presentation layer

\- layering of data. Intelligent hierarchies of data that be queried by other

\- flexible presentation layers that can export variety of data formats web pages as to XML, RSS files, mobile phone SMS, etc.

\- flexible presentation layer(s) that can support different levels of information from a complete archive of past posts to their titles or individual tags

\- metadata ... support things like tags, microformats at a per document level and be flexible enough to allow for more formats that arise.

Of course on top of this you have to build something that others will use, that is bug free as possible in Javascript. Something on or along the lines of Yahoo's YUI ~ <http://developer.yahoo.com/yui/> Maybe this YUI or NewSDK is what Steve Yegge meant when he was talking about the _"Next big language"_ ? ~ [http://steve-yegge.blogspot.com/2007/02/next-big- language.ht...](http://steve-yegge.blogspot.com/2007/02/next-big- language.html)

In all this I can't help think that maybe just solving a few little problems might be a better starting point and if you do so make sure it's the _open web_ and not some roach motel that sucks up data instead of allowing data to flow.

</comment><comment><USER8> All made possible by 6000 packages of ramen noodles provided by pg:

"And Paul Graham gives them another 6000 boxes of instant noodles to eat, so they stay in business another three years perfecting things."

<comment><USER9> This made me laugh too: "But then, while you're sitting on your googlechair in the googleplex sipping googleccinos and feeling smuggy smug smug smug..."

<comment><USER10> Between that and the ramen quip, Spolsky comes across as pretty smug himself.

</comment></comment></comment><comment><USER11> Unfortunately I really think this monopolist might just be Microsoft again. The web operating system is the browser, and when Microsoft start shipping silverlight with IE...

The biggest challenge to this will be getting high performance out of javascript in firefox. Also a combination of svg for graphics and access to the local system via a google gears type api (I see firefox 3 has something like this planned or implemented). While this would all be nicely backwards compatible it wouldn't give you cut+paste support, some sort of MIME support for edit boxes/forms is needed perhaps.

<comment><USER12> If my future choices are being stuck coding in JS, Flash/As or Silverlight, I'm rooting for MS, monopoly or not.

Despite what Joel seems to think, though, I still believe the general trend will be for successful browser apps to move out of confinement of the browser, rather than for successful desktop apps to move into it.

</comment></comment><comment><USER13> I think you are right that there is one entity who will come up with a uniform solution which will just get everybody to adhere to their set standard. What I fail to believe is that this is going to be a language or a SDK.

Instead the real war in the internet will be who will keep your data together and present it to you in a uniform way. This step is already being taken by google with their whole integrate gmail, docs, calendar,... suite. What we are seeing the real Web OS being built and this is not any crap proclaiming to be WebOS.

</comment><comment><USER14> First we need to remember Joel doesn't spend as much time on his blog entries as Paul Graham spends on his. With that in mind - what did Joel mean? Joel meant at leat these two things:

a) Complex design patterns will be refactored into fewer elements. GWT is a nice try but Java isn't simplification - and you Java heads know this.

b) Optimization isn't the only secret sauce to rely on. Companies that put all their eggs in this basket get burned by companies that understand the larger problem begging for a solution. When resource scarcity relaxes, the companies that understand this will automagically appear at the front of the line.

</comment><comment><USER15> Weird I thought the coming web ui monopoly was this little thing called Flash... I guess that's why MS came out with Silverlight and Google's paranoia came up with Google Gears...

<comment><USER16> I don't think so, I still hate Flash, and I am not the only one. In fact, I just switched to Linux, only to find that flash makes firefox crash (seems I was unlucky, it works fine for others). The point: just as always, flash simply doesn't work for everyone, so it is out. The last big company I worked for also didn't provide it's employees with flash.

<comment><USER17> Flash is the only widely available system that gives you full control over every pixel in the browser and it does that in a pretty efficient manner.

Although, yes, something intuitively stops me, too, from getting excited about Flash. Maybe it's that it's closed/proprietary and I just don't trust today's Adobe anymore. They definitely want to be the microsoft of the web.

So there's Silverlight (well, potentially), Flash and still no decent alternative from the open-source world. No Mono/deIcaza stuff please. Thanks.

</comment></comment></comment><comment><USER18> lol @ this line:

"...you'll tell your children how excited you were to get 2GB to store email, and they'll laugh at you. Their _nail polish_ has more than 2GB."

<comment><USER19> That's neither funny nor witty.

</comment></comment><comment><USER20> It's happening already - the contenders are JQuery, Prototype, YUI, Mootools, Dojo, GWT, haXe, etc., along with Apollo/Silverlight/Parakey if you allow desktop plugins. We just don't know who the winner will be yet.

Personally, my money is on JQuery (literally - I'm using it for my startup), but it really is too early to tell. Interestingly, nearly all the "serious" contenders are open-source: it's possible that the developer community learned their lesson from the Microsoft monopoly of the 1990s. It's very difficult to get any sort of programming tool adopted these days unless it's open-source.

</comment><comment><USER21> I think he's missing the point by focusing on the GUI -- it's a uniform userland, not a uniform appearance, that facilitates interoperability. User management, permissions and a model for resources go a long way toward making a platform.

As Firefox, Silverlight & al. become more and more like desktops, virtualization allows Linux to become more like a cross-platform application environment. Web apps often find themselves recreating userland fundamentals. The people at Vita Nuova caught on to this a few years ago, and released a version of Inferno (Unix relative) as a browser plugin.

</comment><comment><USER22> Joel just hit the nail right on the thumb. His hypothetical NewSDK doesn't give javascript any new abilities nor would his NewSDK provide any new ways of using those abilities which couldn't be duplicated in other ways.

</comment><comment><USER23> Of all the Joel articles this one was better than most. As someone else said I see Joel has a very practical kinda guy. He so practical that I don't look to him for setting the future. I've never seen a practical programmer, such as Joel, make anything that is future. I digress. However, his practicality in this article was an interesting slant on the future.

I do believe the next level is making my Google mail work with Flickr or vice versa. Right now all these applications are islands, but there is a lot of benefit to joining them into the larger part. Whatever, that is could be a great thing. Is it just an Web SDK? Is it the real Web OS? It's a practical prediction.

</comment><comment><USER24> So what would it take to make NewSKD? and could it realistically be done by a YC style startup?

<comment><USER25> It would simply take a browser plugin for every type of browser. NewSDK code would be inside HTML comments, just like conditional comments are. The browser plugin would parse this code and cache it (aka compile it). From there, it would be trivial to implement image copy and paste.

Keep in mind that I have no idea what the limitations of a browser plugin are, but if one can:

1) parse the raw source code that's sent down from the server, including comments

2) manipulate the DOM

3) open an outgoing connection

Then you could do, well, anything. Embed Ruby into pages, for example. The reason you can do that is because the Ruby interpreter doesn't have to be a part of your browser plugin. All you have to do is convince users to download your C++ app that DOES contain a Ruby interpreter and runs in the background, then your plugin communicates with that via a socket. Your app then issues commands back to your plugin (you can think of those commands as assembly instructions) which manipulate the DOM or whatever else a plugin can do.

<comment><USER2> I got the sense Joel was talking about an SDK that does not require a plugin. Otherwise it seems Flash and Silverlight already meet his requirements.

<comment><USER25> Hmm.. They meet the requirements to an extent. They're really little islands of functionality. I'm talking about a plugin that can react to and manipulate HTML elements, persist across page loads, and doesn't have browser-specific quirks.

</comment></comment></comment></comment><comment><USER3> _"... new versions of the browsers come out that support cached, compiled JavaScript ..."_

Rhino supports this ~ <http://www.javalobby.org/java/forums/t87870.html> ... [http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compil...](http://developer.mozilla.org/en/docs/Rhino_JavaScript_Compiler) Anyone tried this?

<comment><USER26> But Rhino has nothing to do with browsers.

If you want cached, compiled JavaScript, try Flash Player 9.

</comment></comment><comment><USER27> Joel just blew my mind. Awesome article.

</comment><comment><USER28> I want those 3 minutes back I wasted reading this!!!</comment>


Chicago Immigration Raid Leaves Bakery Short 800 Staff - <AUTHOR> https://www.bloomberg.com/news/articles/2017-11-27/chicago-bakery-s-immigration-issues-plague-otis-spunkmeyer-maker?cmpid=socialflow-twitter-business&utm_content=business&utm_campaign=socialflow-organic&utm_source=twitter&utm_medium=social <comment><USER2> Wow!

A foreign company with a bakery here in the U.S. hired 800 foreign workers and management didn't know it.

I can believe that, but I'd have to be paid a lot to be sure.</comment>


Show HN: Webpack build analysis, for every commit - <AUTHOR> https://packtracker.io <comment><AUTHOR> Hi everyone! Now that JavaScript is TAKING OVER ALL THE THINGS, we've got some really great tools like webpack and the npm registry to help package, bundle, and reuse JavaScript. The combination of these tools is a force to be reckoned with. After working on a few projects that utilized these tools, I recognized a gap in the way we were measuring success.

Long ago in a land far far away (circa early 2000s web development) we would obsess over the size of the code we were forcing our users to download. Public CDNs and dependency free libraries seem to be becoming the exception as we continue to lean into the lie that bandwidth is cheap and compression is good enough.

Many times we can't even answer how any given package is going to effect our delivery size before getting it in front of our users. We've traded in our size conscious, delivery performance obsession in for the admittedly high upside of module systems and bundlers. Cleanly separating and re-using our own code, and making it easier than ever to distribute and utilize code as a community. This is a huge win, but ignoring the delivery profile of our code can cost our users time (especially on that vital first-run experience!).

The goal of packtracker.io is to bring a delivery performance benchmark back into your process and consciousness. To make front and center how your use of webpack and npm affect your delivery profile, and to make those optimizations gratifyingly visible.

I'm currently doing a closed beta with a few people that want to get involved, so feel free to request early access if that sounds interesting.

Hope you'll want to help me kick the tires and see if this thing is useful to you!</comment>


Yahoo breaks every mailing list in the world including the IETF's - <AUTHOR> http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html <comment><USER2> We really want Discourse ([http://www.discourse.org](http://www.discourse.org)) to get to a place where we have extremely robust 100% open source mailing list support -- we now have reply via email, notify via email, and community contributed submit topics via email. Working on attachments via email this week.

It's interesting -- unlike forums, people _really_ enjoy mailing lists. I don't think I've ever met anyone, ever, who said they liked forums. But mailing lists seem to inspire people.

I want to see a long term hybrid model where you can interact nearly completely via email, or a good, modern web UI that _YOUR_ org owns (not google groups or yahoo groups). This should be supported.

<comment><USER3> Forget forums. Forget mailing lists. Bring back NNTP, so we can just point people at com.mycompany.engineering.infrastructure and _not worry about setting up another lame inbox filter_.

<comment><USER4> [http://forum.dlang.org](http://forum.dlang.org) is an NNTP forum. You can also access it via newsgroups news://www.digitalmars.com/digitalmars/D or even a mailing list at [http://lists.puremagic.com/cgi- bin/mailman/listinfo/digitalm...](http://lists.puremagic.com/cgi- bin/mailman/listinfo/digitalmars-d)

It works out quite nicely for us.

<comment><USER5> Wow is their forum software open source/freely available?

I love how snappy they are.

<comment><USER4> Sure: [http://forum.dlang.org/help#about](http://forum.dlang.org/help#about)

</comment></comment></comment></comment></comment><comment><USER6> Having managed a number of largish email systems over the past few years, I've got to say that dealing with Yahoo -- DKIM and other anti-spam related issues -- is one of my larger ongoing headaches. The lack of response and transparency of Yahoo in general is a huge problem -- I managed to get resolution in one case via an executive email carpet bomb (this after repeated contacts with their support team and direct emails to the CTO/Postmaster's address).

Sadly, as much of a fading giant as Yahoo are, their email presence remains huge.

<comment><USER2> Yahoo may be bad, but Outlook/Hotmail are without a doubt worse. Exhibit A:

[http://serverfault.com/questions/434703/why-does-hotmail- sti...](http://serverfault.com/questions/434703/why-does-hotmail-still-reject- my-emails/452896#452896)

<comment><USER7> I disagree. I've had Yahoo reject my emails completely silently (didn't arrive in inbox OR 'spam' folder, even though Yahoo's MX said the message was accepted). Yahoo was entirely unresponsive about this issue. We didn't have the same problem with any other provider and it was resolved immediately upon switching to a third-party email delivery service.

Additionally, Yahoo has a huge amount of abuse and doesn't seem to have an abuse handle either; you have to fill out some form buried deep on their site. On the other hand, I've reported abuse incidents to Hotmail before and have gotten an actual reply from a human (a rarity when submitting abuse reports; most places act on them but don't bother responding).

<comment><USER6> Yeah, don't even get me started on Yahoo's spam emissions and lack of reporting.

</comment></comment></comment></comment><comment> mike-cardwell I played with DMARC about a year ago. I put it in monitoring mode so that I'd get email reports from systems to tell me when they received emails from my domain which failed DMARC. I started getting them from all over the place. Pretty much all related to mailing lists breaking the DKIM signature by rewriting headers or the body. My conclusion was: If any email address on your domain subscribes to one or more mailing lists, DMARC will break your email. I disabled it. I don't see myself enabling it again any time soon.

</comment><comment><USER8> We noticed noticed last month that one of our Yahoo! Groups mailing lists would randomly drop emails[1]. We couldn't find any consistent behavior to it. Wonder if this is the culprit.

[1] [https://twitter.com/jmathai/status/440529845198790656](https://twitter.com/jmathai/status/440529845198790656)

</comment><comment><USER9> So what should Yahoo do? Change settings to say "Actually, anyone in the world can send emails from @yahoo.com now."?

(Honest question.)

<comment> mike-cardwell Yes. If they want their users to be able to use mailing lists.

<comment><USER9> Is that the trade-off? Either we neuter SPF et al or we break mailing lists?

I vote for SPF et al.

<comment> mike-cardwell Yes, that is the tradeoff.

SPF doesn't really come into it. Mailing lists use their own sender envelope. The problem is, when a mailing list makes changes to an email which breaks the DKIM signature. But the sender uses DMARC to say that DKIM _must_ pass.

Another fix would be for all mailing lists to be updated to not make any changes to messages which might break DKIM. E.g by adding [listname] to the subject line, or messing with other headers, or adding signatures to the body.

<comment><USER10> The tradeoff isn't that bad: it's possible to make mailing lists work with DMARC, see for example their suggestions in the FAQ: [http://dmarc.org/faq.html#s_3](http://dmarc.org/faq.html#s_3).

It can be argued that the required changes are very burdensome and not mailing-list-friendly. The mail body modifications seem to me like something mailing lists could drop taking advantage of the list-* headers instead. The harder usability issue arises from the fact that DMARC imposes a different way of setting the from header potentially breaking all those filters we've set up.

DMARC claim both issues can be solved using "Original Authentication Results" header but since it requires the receiving MTA to trust the mailing list the administrative overhead here just doesn't scale and will likely end up being pushed onto the list admins.

Also, SPF _does_ come into it since DMARC requires "alignment" between the from domains in the envelope and the header (see again the FAQ answer above).

<comment> mike-cardwell My point about SPF not coming into it, was made because SPF _will_ fail in a forwarding/list setup. DKIM _can_ work in this setup, so that's what we want to make work, but which all mailing list software seems to break.

</comment></comment></comment></comment></comment></comment><comment><USER11> DMARC.org has very clear remedies.

Q: I operate a mailing list and I want to interoperate with DMARC, what should I do?

A: DMARC introduces the concept of aligned identifiers. It means the domain in the from header must match the d= in the DKIM signature and the domain in the mail from envelope. You have a few solutions:

\- operate as a strict forwarder, where the message is not changed and the validity of the DKIM signature is preserved \- introduce an "Original Authentication Results" header to indicate you have performed the authentication and you are validating it \- take ownership of the email, by removing the DKIM signature and putting your own as well as changing the from header in the email to contain an email address within your mailing list domain.

Spoofing is a huge issue for all email customers. DMARC was started, in part, to deal with the coming problems that were foreseen here. Mailing Lists don't have to forge or spoof to work. They can adjust and everyone is better off.

<comment><USER10> (the post above has been largely copy-pasted from [http://dmarc.org/faq.html#s_3](http://dmarc.org/faq.html#s_3))

Interesting point for the discussion on whether MLMs are allowed to modify the from header is in the section 3.6.2 of rfc 2822: [http://tools.ietf.org/html/rfc2822#section-3.6.2](http://tools.ietf.org/html/rfc2822#section-3.6.2). The intended meaning of the from field is to indicate the _author_ of a message which is explicitly allowed to be different than the sender. Thus list-originated communication like digest messages should be sent with the from header of the list, but messages forwarded by the MLM should be sent with the from header indicating the _original author_. In the absence of the sender header it can be assumed to be the same as the from header. Thus, DMARC could use the sender header instead of the from header and fall back to the from header only when sender is absent. This way MLMs would have a way of avoiding the issue by supplying the sender header. Unfortunately, DMARC chose not to use the sender header citing abuse and bugs in some MUAs which don't display the sender header to the user correctly: [http://www.ietf.org/mail- archive/web/dmarc/current/msg00064....](http://www.ietf.org/mail- archive/web/dmarc/current/msg00064.html).

As for the "Original Authentication Results" it doesn't solve the problem for most lists since it requires the destination domain to explicitly trust the list, see [http://www.dmarc.org/pipermail/dmarc- discuss/2012-February/0...](http://www.dmarc.org/pipermail/dmarc- discuss/2012-February/000428.html) and [http://tools.ietf.org/id/draft- kucherawy-original-authres-00...](http://tools.ietf.org/id/draft-kucherawy- original-authres-00.txt). Few list admins could afford getting a trust explicitly established with every domain where the members happen to have mailboxes.

</comment></comment><comment><USER12> For this to fail, wouldn't the mailing list have to send the message on to its subscribers listing it as "From" the Yahoo email address? In that case, it's the mailing list doing it 'wrong' (in the eyes of SPF, DKIM, et al, anyway), as they should be sending it 'from' their mailing list email address, not the original person who sent the message. This isn't a new problem as SPF has required mailing lists to do this for years now.

*UPDATE: Clarified 'wrong' wrt the various protocols.

<comment><USER13> > For this to fail, wouldn't the mailing list have to send the message on to > its subscribers listing it as "From" the Yahoo email address?

Yes, which many mailing lists do.

> In that case, it's the mailing list doing it wrong

Is it? Not having the actual originator as the "From:" seems to be "doing it wrong".

<comment><USER14> Exactly, and "From:" has "always" been expected to possibly be a different identity to the sender of the e-mail: We have "Sender:" to indicate where the message was sent from when "From:" does not.

</comment></comment></comment><comment><USER15> I'm amused to note that this probably applies to Yahoo Groups as well, since it uses the yahoogroups.com domain, not a yahoo.com domain.

Looking at the headers of a recent message from a Yahoo user over Yahoo groups it seems like it would be the case:

      dkim=pass firstname.lastname@example.com;
      dmarc=pass (p=REJECT dis=NONE) header.from=yahoo.com

Of course, anyone who is using Yahoo Groups regularly has probably noticed that even with last year's redesign it's not getting much attention.

</comment><comment><USER16> Please forgive my naivety—why are mailing lists forging from addresses in the first place? Have they just been fragilely dependent for years on the exploitation of an authentication vulnerability?

<comment><USER17> Fair question. The basic internet email spec has virtually no security features whatsoever, and is completely unauthenticated. Mailing list management software doesn't forge sender information, but rather often retains it and generally trusts incoming headers. Back in the old days, some folks even referred to discussion lists as "reflectors."

The proper usage of SMTP mail headers is outlined in RFC2822 (originally RFC822), and the definition of the headers From, Sender, Resent-From, etc. The rules for specifying sender information are spelled out in 3.6.2. [0]

That said, system behavior also depends on if the MLM software is running behind a mail transport agent that enforces authentication protocols for incoming emails, scans for viruses, etc.

When discussion list owners are concerned about receiving forged posts, they usually use list moderation features so they can ensure emails do not get distributed that haven't been reviewed first. But the biggest problem for MLMs isn't usually dealing with impostors, but rather blocking email-borne viruses and misconfigured auto-responders that could cause bogus emails to get reflected out to subscribers.

The behavior of the outgoing From header from MLM software typically depends on the configuration of the list. Some lists (especially digests) are configured so outgoing messages are "From" the list itself. But most discussion lists are configured to retain the original From line, while clarifying their role as an email proxy through other headers.

[0] [http://tools.ietf.org/html/rfc2822#section-3.6.2](http://tools.ietf.org/html/rfc2822#section-3.6.2)

</comment></comment><comment><USER18> This and SpamCop flagging a bunch of Google's mail server IPs broke a bunch of email last week.

</comment><comment><USER19> I don't use Yahoo anymore because it runs very slow for me..

</comment><comment><USER20> So would this explain a spam email in my hotmail inbox that had the same From&To, with no mention of my actual email in the raw message source?</comment>


Show HN: Unlike App - <AUTHOR> http://unlikeapp.com/

<comment><AUTHOR> This was just a short weekend project. Someone posted a fake "unlike" app before, and I wanted to see if I could throw together a real one in 2 hours.

I used some of the effects from my framework to make it quick and slick. Let me know if you encounter any bugs on your local environments / browsers.

The only thing is - you can't really unlike anything because the app needs to be whitelisted by facebook.

This app is completely open source, and I encourage you to fork it. If any of you want to, you can juts copy & paste the HTML and it host it somewhere. Just register your own facebook app id. If you're able to improve it, please post the URL here. If you're able to get your app to be whitelisted for the "unlike" to actually work, definitely post here :)</comment>


Power Law and the Long Tail - <AUTHOR> http://avc.com/2015/11/power-law-and-the-long-tail/ <comment><USER2> > The best thing you can do for this long tail is find a good home for the > portfolio company. That could be everything from a modest acquisition to an > acqui-hire. If you have to do a shutdown, then I like to see it done on > terms the entrepreneur can live with.

There was a question here along time ago asking if venture backed companies had better outcomes than non venture backed ones and the above quote is very close to what my response was.

When you take VC, you have a very powerful and connected person in your corner who will fight for you from the start to the end. And if things don't work out then all other things being equal I'd guess you have a better than 10x chance over a non VC taking firm of having a "soft landing" via an aqui-hire.</comment>


Google Checkout Closing Down on Nov. 20th - <AUTHOR> https://support.google.com/checkout/sell/answer/3080449 <comment><USER3> I can't imagine ever building something that relies on a Google service at this point.

There is a lot of collateral damage when they do things like this, damage that hurts them when even when it comes to developers like me who've never written a single line of code that integrates with Google Checkout.

<comment><USER4> Yeah, but how many business was using Google Checkout as only method of payment? This decision will hurt only those businesses. Rest of businesses using Google Checkout will remove one of payments method. Not a big deal, and we may guess that this method was probably not so popular already.

<comment><USER5> My startup for a time being was only using Google Checkout. Here lies the problem. Can't trust Google with building APIs when they reorganize.

This is surprising to me, but I wonder if Google Maps could close down....

<comment><USER6> > I wonder if Google Maps could close down....

No. Google has bought what must be dozens of companies at this point just to support and improve Maps (Waze being the latest), it's reportedly profitable & popular, with the continued rise of mobile I'd expect it to become more important, and my little survival analysis ([http://www.gwern.net/Google%20shutdowns](http://www.gwern.net/Google%20shutdowns)) gives it 87% odds of surviving to May 2018 (which IMO is too low).

<comment><USER7> Also there are a bunch of government people who work on it I think.

I saw a bunch of public linkedIn profiles with NSA analysts and people in the private sector with google maps listed as experience for whatever reason

<comment><USER8> Google maps and Google earth are used extensively for imagery analysis and intelligence work. They aren't working with the maps team so much as using it as a tool.

</comment></comment></comment></comment></comment></comment><comment><USER9> I think failures of projects such as this can be attributed to wrongly applying lean principles instead of coming out with a more complete offering. Checkout never really matured as a product and therefore made for a poor PayPal or merchant account alternative.

<comment><USER10> As a former Google Checkout/Wallet employee, this is completely right. When Checkout was first released, companies would get free AdWords credit to sign up and use the service. Also, non-profits got free processing. After this initial release and push to have this product adopted, nothing was done to move it forward. There were no updates and improvements made. The only changes were when patches and bug fixes for problems that affected a large amount of customers (not surprising since it is impossible to fix every issues that affects every customer, but when you are dealing with a product that some companies solely use to make a living you better try hard to fix as many problems as possible).

<comment><USER11> > _After this initial release and push to have this product adopted, nothing > was done to move it forward._

That describes _so many_ Google services. Some live on anyway, because for whatever reasons they meet Google's interests to keep running (Google Books). Some don't.

</comment></comment></comment><comment><USER12> If you want large companies to innovate (and I do) you can't complain bitterly if they fail and retire a product or service in this way (which as others have noted included a lot of notice) The flip side is big companies won't innovate or release anything new. "No way! Have you seen how people complain if we have to close it down? Not worth taking the chance of all that bitching"

P.S It's kind of funny that one of the alternatives they pushed at the time of the initial announcement was Braintree who then went on to be acquired by PayPal. Shows you how fluid/active this space is.

<comment><USER13> So why not do it faster to avoid people relying on the service for many years? Set a private internal deadline of 6 months or a year, then if it's not as successful as your initial goal, kill it then, not seven years later, after tons of people have come to rely on it.

<comment><USER12> Again you're just craving this predictability and risk reduction which is at loggerheads of taking chances and entering new markets.

</comment></comment></comment><comment><USER14> This actually solves a problem for me. For a long time, "finish Google Checkout recurring billing integration" was on my todo list. Just didn't get to it due to limited time and confusing documentation. Now I can simply close that ticket.

<comment><USER15> To be fair, even PayPal screws up recurring billing.

<comment><USER14> After having integrated nearly a hundred payment services: To be fair, recurring billing is hard.

<comment><USER16> Care to share an opinion on who does it best? Or least worst?

<comment><USER14> Can't really pick a best. The reason why I write that recurring billing is hard is because the business cases vary so widely, so the answer is usually: It depends (on your location, userbase, what you're selling...). I started out writing a couple of integrations and you think "hey, why are there so many processors, that's unnecessary!". And then you do a couple dozen and you start to see the picture.

I CAN definitely tell you how to spot the worst, though. In general, when you read the documentation and get the creeping feeling like the API was written for one big client (and their weird business logic) and then they just packaged it up and resold it, badly.

Funnily enough, Google Checkout seemed to be like that to me - for instance, usually you have two things to specify: Time unit and amount of your billing cycle, like "recur every 4 days". Google Checkout didn't do that, no no, much too simple. They only had a time unit - one of: daily, weekly, semi_monthly, monthly, every_two_months, quarterly, yearly.

And that's not the most complex "let us structure time awkwardly" example I have seen over the years. Other services only allow for "days" as time unit and you have to figure out a way to do monthly billing that doesn't just keep running away. My favorite so far was the one where it's basically "day, week, month, quarter, half-year and year". The values for that? D, W, M, Q, _6_ , Y. Can't make this stuff up.

Other red flags: No English documentation, no public documentation, documentation that specifies variables without data types, unsafe notification functions (not even a shared secret) or downright exotic "security" (I have seen black-box .dll files distributed as security callbacks... oh the horror)... I could go on.

<comment><USER17> If it's any consolation my bank pays off my credit card every 30 days. When I signed up the credit card would get payed on the 1st of the month. Over the years that date has drifted to now be the 20th. So even the big players haven't solved this recurring payment problem.

<comment><USER15> I still think that offering "every N days" and "Nth day of the month" would cover 99% of use-cases. The big problem I ran into was when my credit-card expired, PayPal paid a recurring bill late as it had to do an "e-cheque" that had a long delay on it. So the payment happened late.

The WTF happened the next month, after I fixed the credit card issue - <USER2> future bill had the same long delay on it. Somehow their "Pxtl pays on X day of the month" had gotten shifted. So I was getting late notifications _every month_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> This is nothing new, the Nov 20 date was well-known back in May:

[http://www.engadget.com/2013/05/20/google-checkout-for- merch...](http://www.engadget.com/2013/05/20/google-checkout-for-merchants-to- be-retired-on-nov-20/)

</comment><comment><USER19> Which prompts the question - should you bother signing up for Google Wallet (if applicable, i.e. digital goods only). Since that may just end up suffering the same fate.

<comment><USER20> I think it's safe to say that Google will not be getting out of payments any time soon. Wallet is already tied into the enormous Play Store, so they certainly have a healthy userbase, and seeing as Google primarily is a digital services company it makes more sense for them to not target physical goods.

<comment> mh- I don't think one should read much into them needing Wallet internally.

Google needing to accept credit card transactions for the Play Store is almost tangential to the service: offering a supported API to 3rd party merchant- users for processing digital goods transactions.

The latter involves risk assessment, underwriting, customer support, maintaining card association/acquirer relationships, so on.

</comment></comment></comment><comment><USER21> This is insanely bad timing. They should shut it down in January of 2014 after all the E-commerce retailers make all their money.

No one in Ecommerce wants to touch their tech stack during the only quarter that matters to them.

[edit] Apparently the shutdown was announced in May. Regardless, it probably would have been better to shut it down in September, than right before Cyber Monday.

</comment><comment><USER22> Google Checkout has been depreciated since May. It's not like this come as a suprise.

<comment><USER11> the word is 'deprecated'.

'depreciated' is a different word.

<comment><USER23> <3

</comment></comment></comment><comment><USER24> If you think Google shuts down APIs this quickly and casually now, wait until after the stock market bubble bursts.

<comment><USER18> This is old news from months ago. The Nov 20 date was mentioned back in May:

[http://www.slashgear.com/google-checkout-to-be-retired- novem...](http://www.slashgear.com/google-checkout-to-be-retired- november-20-20282862/)

</comment></comment><comment><USER25> Title switching to _slightly_ less informative "Retiring Google Checkout Announcement" in 3, 2, 1...

</comment><comment><USER26> I'm still annoyed that iGoogle is going away. I've tried some alternatives and still haven't found one I like as well. And now it reminds me every day that its going away. Ugh.

<comment><USER27> Which parts of iGoogle (fragments) did you actually use?

<comment><USER26> I use it mostly for RSS feeds, which come in a surprising variety of formats that not all of iGoogle's would-be replacers can handle. I also have a weather app, the Gmail app, and I like that I can read at least a portion of some stories directly within it without going to the website.

</comment></comment></comment><comment><USER28> This is probably because requestAutocomplete has been moved into Chrome Beta, and will probably feature tight Wallet integration.

[http://www.chromium.org/developers/using- requestautocomplete](http://www.chromium.org/developers/using- requestautocomplete)

<comment><USER29> More likely was Checkout With Amazon.

<comment><USER30> I don't think Checkout with Amazon has affected them at all. Checkout was closed to new signups since May 20th (from the article), and Wallet has been the digital-goods alternative for longer than that.

My guess would be that operating a physical goods processing company is a huge drain on the resource Google hates providing most: customer service.

Payment disputes are a pain, especially for physical goods. Some level of mediation is required when someone has purchased a physical good but has a dispute. But with digital goods you can just tell the seller to eat it (digital good, no actual cost loss)

<comment><USER10> Google never had great customer service for this product. There were less than five people (customers often called this out since they would submit multiple help tickets and the same people would respond) and they never wanted to devote money to better customer service since the product wasn't maintained. Thus companies didn't want to adopt a below par product with bad customer service compounding the problem.

</comment></comment></comment></comment><comment><USER31> While Checkout was deprecated for months, this marks the fourth in several huge shutdowns by Google. Reader, iGoogle, AOSP, and now Checkout. Not to mention their 3E mantra with companies like Sparrow and QuickOffice.

Is there any way that Google can even be thought of as not evil anymore?

I'm slowly shifting everything away from Google. I'm using an iPhone 3G as my main smartphone; switched to DuckDuckGo as my search engine, and have switched my email to private hosting for anything confidential and Outlook for public email.

There's really nothing they could do, good or bad, to get me back at this point. They've proven, time and time again, that they don't care about the customer, and frankly, I'm tired of it.

<comment><USER32> It's a bit of an exaggeration to say that AOSP was shut down.

<comment><USER31> Well, without Google's proprietary Play Services, it's practically unusable by itself.

</comment></comment></comment><comment><USER33> Checkout isn't mentioned on Gwern's predictions for google product closure: [http://www.gwern.net/Google%20shutdowns](http://www.gwern.net/Google%20shutdowns)

I hope he updates the page now that we have this additional data point, I'd love to see how his predictions performed.

<comment><USER34> That's because his post is newer than the announcement that Checkout would close. It was probably in his "Dead products" list.

<comment><USER6> It's actually in the followup list. I added it 152 days ago (21 May 2013) when [https://news.ycombinator.com/item?id=5740447](https://news.ycombinator.com/item?id=5740447) hit HN announcing the closure of Checkout in November, but that apparently was after I closed down data collection so I could finalize the analysis. (Wow, did I finish that analysis that long ago?)

From my notes, I'm confused about how to treat it. The discussion in [https://news.ycombinator.com/item?id=5740447](https://news.ycombinator.com/item?id=5740447) among various HNers suggests that it's sorta like Checkout is becoming Google Wallet, but also sorta not, so I'm not sure whether to consider this one of the transition/renamed products or whether Checkout was killed and Wallet happens to have some similar functionality.

</comment></comment></comment><comment><USER35> This isn't "news", I was notified months ago.

</comment><comment><USER36> Scared, shocked and confused for a moment while I thought Google was shutting down _Takeout_ (which would've been a huge step backward.) This is okay (it's been superseded by Google Wallet anyway.)

<comment><USER37> It's apparently been superseded by Google Wallet for digital goods and discontinued with no replacement for everything else, if I'm reading the announcement right?

<comment><USER38> \---

No, Google is not offering a replacement processing solution for physical goods and services. We've partnered with three premier players in the payments industry to offer alternatives for your eCommerce needs. The links below will guide you to more detailed information about each offering, including negotiated discounts for Checkout users:

Payment Processing: Braintree Payments

Hosted storefront: Shopify

Email invoicing: Freshbooks

\---

Increasingly often I'm associating Google with poor customer service, poor design and being indifferent to user worries when discontinuing products. Not sure they realize the harm they are causing to their brand, even in the eyes of people who don't actually use the affected products.

<comment><USER39> Google have gone from (in my opinion) almost flawless execution to a complete mess, they do stuff that drives me away on an almost daily bases.

For example.

I've signed into my Gmail and then visit youtube "Do you want to create a Google+ profile" NO "Ok, we'll ask again later".

Sign into the admin account for google apps I run for a charity I volunteer at while signed into my work account "connect these two accounts?" NO "Ok, we'll ask later".

Reset my android phone, "Play" doesn't work because their is a blocking modal accept terms dialog that isn't on screen, I have to swipe close play then re- open it.

Still can't switch primary domain on a google apps account without setting up a new one, migrating data over and shutting down old one.

Asking me for my mobile number as a 2nd fallback for my password, NO, if I give you that you already know my android phones number and now you know without a shadow of a doubt who my work account belongs to (it's the obsequiousness that gets to me).

Catchall email address still don't work for no apparent reasons.

Documentation is an utter and complete mess for Google Apps (referring to multiple versions of the google apps interface, which change about once an hour anyway).

\</comment></comment></comment></comment><comment>

I don't want a google+ account, I don't want to connect all my google accounts as some are work, some are private and some belong to charities and such I volunteer for.

I don't want you to ask me for other personal data _all the time_.

I will stop using all google services soon if this continues down that path, It's my business I can use anything I want and the level of crap is fast approaching moving all my stuff back in house.

I suspect I'm not the only one who feels like this.

<comment><USER40> People so vocal about these types of frustrations are the same people who keep refusing to just unify Google's services. You have multiple Google accounts so link them then that's the end of it.

There are much more important things to worry about like Youtube's copyright policies.

By being driven away, what you mean is they are doing things to move forward and you want it to stay the way it was. Since that isn't going to happen you are annoyed and want to bash Google's reputation.

Android, Google Docs, Hangouts, Maps, and yes, Google+ are all amazing free products. Google Checkout is going away because Google Wallet is their new thing. The company is fine and their reputation is fine. A couple of stubborn people are being left behind in a sea of "do this now" notifications because they keep not doing them. Sorry to be so brash. But each of your accounts still remain "separate" after you link them. There are extensive privacy settings for every piece of information you put online using Google+ so it is not a chore to keep charity work separate from work separate from personal. It's actually quite elegant.

I don't understand, is it because you are used to using aliases? Why do you want to fight this so hard?

<comment><USER41> I think this comment is a great example of the disconnect. You (and I presume a majority of the people working for Google) are not actually able to even comprehend why people might want multiple accounts, or to have separate accounts for their email and their video watching and their blog. He even gives examples in his post, like administering an account for a charity organisation, but somehow things like that are unimaginable to people in the Google bubble.

It's pretty worrying when a company can't even understand the basic motivations behind the actions of their users: how can they possibly weigh up the costs and benefits of forcing account consolidation when they can't even imagine the use cases where consolidating accounts doesn't make sense for users.

<comment><USER42> I doubt the person you're replying to works at google. His profile says he is a ruby developer and as far as I know we don't use that. Also, his attitude is not particularly common within google.

<comment><USER41> I didn't mean to imply that I think he works for Google.

>Also, his attitude is not particularly common within google.

So the majority of Google engineers disagree with the policies of the management? Do people internally push back against this stuff (trying to force account consolidation and making everything part of G+), or are people too afraid to speak out? If people aren't happy with it, how far does it have to go before morale drops and people start looking for other jobs?

<comment><USER43> Google is a big place and there's lots going on, both good and bad. There is lively internal debate and plenty of pushback, but there are also good reasons to stay even when you disagree about a particular issue. There are people who leave, but someone who's unhappy might just switch to a different team.

</comment></comment></comment></comment></comment></comment><comment><USER23> I think the difference between "old Google" and "current Google" is that old Google would have been honest and said "the closest available equivalents are Paypal and Amazon Payments". Instead the migration partnership (presumably with a rev share) is Braintree, which while capable is not really the same sort of product.

It sucks to have to close things down, but sometimes you do, and they gave everybody 6+ months of notice to migrate back in May, but being disingenuous about the best alternative is mealy-mouthed and "un-Googly".

</comment><comment><USER44> Specifically:

* Merchants selling digital goods may transition to Google Wallet for digital goods

* Merchants selling through Google-hosted marketplaces (e.g. Google Play) will be unaffected

* Merchants selling physical goods will need to switch to third-party alternatives (see below)

\-- [https://support.google.com/checkout/sell/answer/3080449](https://support.google.com/checkout/sell/answer/3080449)

</comment><comment><USER45> The only thing Google will never shut down is ads.

</comment><comment><USER46> There are many webdev learning books that used Google Checkout and built an app using their service as an example.. It will be fun for people reading the book after a couple of years about a service that doesn't exists anymore, it'll be like reading some sacred scrolls from times forgotten by today's humans..

</comment><comment><USER47> Google are generating a lot of uncertainty in their product offerings lately. To innovate you need to know when to call it quits and move onto something else. It's quite clear Google Checkout wasn't the success that Google had hoped it would be and are closing it down to divert resources and cash somewhere else where it might be better utilised. People will complain about this situation, but would you rather Google kept a service running just to appease a few die-hards when it's probably costing them money?

We need stronger and tougher competition in the online payments space. Paypal seriously can't be the only globally working payment and checkout substitute around, maybe Google has a similar service that's stronger and more feature packed up their sleeves? I hope so.

</comment><comment><USER48> While this seems bad from the title, it's actually pretty good. They are consolidating redundant systems into one system: Google Wallet.

<comment><USER49> But Google wallet can't be used if you sell physical things.

<comment><USER50> Yet... I'm Norwegian so the Play Store only contains apps, as such I have no idea if ordering Nexus devices means using Google Wallet or something else entirely, what's the deal there?

</comment></comment></comment><comment><USER51> What is the difference between google wallet and google checkout again?

</comment><comment><USER52> Thanks for eating up more than $3000 from my company, Google Checkout.

</comment><comment><USER53> I'm just starting a new SaaS project. Google was immediately checked off as a source of anything for the project as it is too hard to know if the service will exist in a year.

</comment><comment><USER54> It will be replaced by 'Google Bitcoin'.

</comment><comment><USER55> Didn't google give out millions in coupons for using their checkout last holiday season? (maybe it was 2011)

</comment><comment><USER56> I'd say that signs of an imminent merge with Google Wallet were clearly visible throughout the year...

<comment><USER29> Except they arent merging. Goolge is no longer sulporti g pyshical goods.

<comment><USER56> "Merchants selling digital goods may transition to Google Wallet for digital goods"

Except they are. But I'd say we are both correct.

<comment><USER57> physical != digital

</comment></comment></comment></comment><comment><USER58> WOW and it is right in the middle of the Christmas RUSH! Never Depend on Google!

</comment><comment><USER59> wow, I'm glad I didn't use Google checkout for anything important..

</comment><comment><USER60> i think square has come up with a very good idea thats going to change the payment systems

<comment><USER61> Don't worry, Google will buy them and shut them down too.

<comment><USER62> Why would you think that? It's not like Dorsey needs the money, Square are doing genuinely innovative things and I very much doubt they would be interested in selling to BigCorp.

<comment><USER12> When you take that much VC money you either have to IPO or get acquired by BigCorp. I doubt given Square's land grab that their underlying financials are very attractive so that would rule out IPO for a long time. So.....

</comment></comment></comment></comment><comment><USER63> If this was because checkout was a commercial failure they need to make that public knowledge. Otherwise this does make it seem like you can't rely on any Google product that's not part of their core offering. I'm specifically thinking of Google Voice & Keep.

<comment><USER11> How would it help you to know that it was a commercial failure? How would knowing that change your conclusion that you can't rely on Google products?

</comment></comment><comment><USER64> I know that a significant set of people here are saying that this is "end of Google". Actually, this is "beginning of Google". Google _must_ focus on things they are best at: advertisement.

The problem with their approach of having many half finished products that they were actually helping competition: they were discovering and validating market which is then captured by smaller companies.

And my prediction is that the following Google products will probably die out soon:

* Google App Engine - competition is improving at rapid pace and it is hard to keep up without focus.

* Google Blogger - they will probably just make something similar under Google+

* Google Groups

Probably there is more... but these are the one I see.

<comment><USER27> App Engine — are you serious? New releases every few weeks, quite a few innovations technology-wise and essentially no freeriders. Also, I don't see a lot of competition in terms of equivalent solutions; if at all.

<comment><USER64> I can be wrong about App Engine. Here is my reasoning...

I think App Engine does not fit nicely into Google's grand vision: which is mobile, social, and search for advertising purposes. So they need to be become profitable soon or they will be shut down.

However they lack enterprise customers and without enterprise and corporate customers it very hard to make things profitable.

<comment><USER65> This is wrong. AE is profitable. They have invested so much into AE. Every year at I/O since AE was launched, Google has been presenting the progress in AE. Many of the top companies today are using either AE or EC2 (or both). It is impossible for them to drop AE. They might consider moving away at some point, but in the next 5-10 years it is impossible. But the longer the service remains running, the harder it is for both Google and customers to move away. Eventually, if someone crazy, more competitive comes along, and when customers fall behind they will begin a deprecation and that deprecation period will be years long. When that does happen, Google is no longer attractive. Google will not profit anymore.</comment></comment></comment></comment>


Open Letter Google:Let Us Sell Our Apps.Petition from African Software Developer - <AUTHOR> http://diggletech.digolodollarz.co.zw/2016/01/01/open-letter-to-google-let-us-sell-our-apps-a-petition-from-an-african-software-developer/ <comment><USER2> For many countries, I suspect that international sanctions, a lack of a banking system or a lack of international agreements on transferring money except via Western Union will be a roadblock.

Also the African continent just isn't a profitable enough market for the "big players" when compared to US, EU and Asia.</comment>


Secret Memos Show the Government Has Been Lying About Backpage All Along - <AUTHOR> https://reason.com/2019/08/26/secret-memos-show-the-government-has-been-lying-about-backpage/ <comment><USER2> > "At the outset of this investigation, it was anticipated that we would find > evidence of candid discussions among [Backpage] principals about the use of > the site for juvenile prostitution which could be used as admissions of > criminal conduct," wrote McNeil and Swaminathan in their 2013 update. "It > was also anticipated that we would find numerous instances where Backpage > learned that a site user was a juvenile prostitute and Backpage callously > continued to post advertisements for her. To date, the investigation has > revealed neither."

So, they found no evidence for the things that Backpage was alleged to have engaged in. And they decided to bring charges anyway?

There was a similar situation up in Seattle where a group of sex workers and clients got busted. Police referred to the operation a human trafficking ring and called the women sex slaves. The was no evidence that the women had any nonconsensual sex - the police justified their allegations that these women were enslaved by pointing out that some of the women were in the US on expired visas and that it is policy to assume that sex workers on expired visas are victims of human trafficking. This eventually led to one of the clients killed himself.

It's pretty astounding how much damage people are willing to cause to keep people from selling sex.

<comment><USER3> That's pretty much the case with just about every "sex trafficking" bust, isn't it? Lots of talk about rescuing children and what not, but in the end women, who are supposedly being helped, are hauled off to the slammer, customers, too, and not a single trafficking victim is found. But that doesn't make for good headlines, so the latter part is rarely reported.

Backpage got caught in a perfect combination of "baptists and bootleggers" where, except for people who actually do try to help trafficking victims, exploited kids, etc., who all found BP quite useful and cooperative, everybody, left and right, wanted to shut it down for purely ideological reasons. In the end, nobody came out ahead.

<comment><USER4> It's doubly sad because sex trafficking definitely exists (cf Epstein) but finding some single mom giving handjobs to widowers is much easier for cops to handcuff and call "sex trafficking."

<comment><USER3> Oh, definitely. I'm sure that even the kind of trafficking that Backpage was accused of aiding and abetting also exists, although obviously to far lesser degree than people who feed off of fighting it would want us to believe. But busting some Chinese grandma giving handies in a parlor (after getting some at taxpayers' expense) is so much easier than running after gangbangers, and gives points with voters, so that's what we get...

</comment></comment></comment></comment><comment><USER5> > "Information provided to us by [FBI Agent Steve] Vienneau and other members > of the Innocence Lost Task Force confirm that, unlike virtually every other > website that is used for prostitution and sex trafficking, Backpage is > remarkably responsive to law enforcement requests and often takes proactive > steps to assist in investigations,"

And you wonder why people hate the authorities. You would think that psychopathy among the justice department would lead to careers of all people involved being destroyed, yet it seldom happens and often not for years after when they have had plenty of time to do much more damage.

</comment><comment><USER6> We are suppose to be able to trust law enforcement, and the judicial process. Its difficult when they lie, do it for more power, and then lie about it again and again. This is not an eye opener, but more proof we cant trust those in power. Good article!

<comment><USER7> You're tarring all law enforcement officials with the same brush.

In the article, there's some very honest-sounding acknowledgement by officials of the efforts of the company to cooperate on some concerns (e.g., child exploitation), and also some apparent straight-laced belief in higher evidenciary standards for illegal things they seemed to believe/suspect were going on (e.g., intentionally facilitating adult prostitution).

I think the perseverance of that kind of honesty and belief in principles gives some hope, despite various discouraging things we can also see in society, from all directions.

</comment></comment><comment><USER8> I, like many, am not surprised at all.

</comment><comment><USER9> FYI, reason.com is considered to be right-center biased: [https://mediabiasfactcheck.com/reason/](https://mediabiasfactcheck.com/reason/)

<comment><USER10> Seems like a good article though.

<comment><USER11> Well, the bias fact check site _does_ give reason.com a favorable grade.</comment></comment></comment>


Ask HN: Does anyone maintain a list of must read essays on software? - <AUTHOR> <comment><USER2> [http://sunnyday.mit.edu/16.355/](http://sunnyday.mit.edu/16.355/) is such a list

<comment><AUTHOR> Thank you</comment></comment>


Bakersfield cops and CHP beat man to death while he begs for his life - <AUTHOR> http://www.bakersfieldcalifornian.com/local/x568091070/Dad-who-died-during-arrest-begged-for-his-life-cops-take-witness-video

<comment><USER2> Was anyone on HN under the misapprehension that there was no police brutality in the US, or even that the police don't routinely murder people? There are 790,000 police officers in the US, and we're only just now barely starting to transition to a society that values oversight and controls over policing.

I think the answer to both questions is "no". Nobody is surprised by this.

And so I say there is very little value to this post, other than to generate a caustic political thread.

I'd also argue, as I have done incessantly on HN, that if every important social justice story that happened around the world, or even just in the US, or even just in California! had a hearing on HN, the front page would be nothing but social justice stories. There are other venues on the Internet that offer that kind of forum. HN isn't one of them.

I flagged this story, and I think you should too.

<comment><USER3> I think there's an element here that has a lot of relevance to HN, although it's not called out in the headline: The seizure of phones. I think we all understand that the evidence on those phones will never see the light of day, and that nobody will ever be prosecuted for its destruction. But it would be easy to prevent that outcome -- just ensure that the evidence is transmitted to the cloud before it can be destroyed. There are already apps that do this, but the ones I've seen aren't designed for a life-or-death situation, and can't be counted on to do it reliably. Do we have any that can?

</comment></comment><comment><USER4> Don't ever talk to or cooperate with the police except as a last resort. Police are more dangerous than organized criminals because they are immune to the law, and they know it. Never open your door for a police officer. If you must interact with the police, have a lawyer present at all times. It is literally a matter of life and death.

Cops break and enter and commit murder, with no criminal charges brought: [http://en.wikipedia.org/wiki/Killing_of_Kenneth_Chamberlain,...](http://en.wikipedia.org/wiki/Killing_of_Kenneth_Chamberlain,_Sr).

Cop kills in cold blood, receives a 6 months jail sentence: [http://en.wikipedia.org/wiki/BART_Police_shooting_of_Oscar_G...](http://en.wikipedia.org/wiki/BART_Police_shooting_of_Oscar_Grant)

Minneapolis Gang Strike Force confiscates property for officers' personal use from minorities. No charges were brought against the officers: [http://blogs.citypages.com/blotter/2009/08/report_rampant.ph...](http://blogs.citypages.com/blotter/2009/08/report_rampant.php)

<comment><USER5> Good advice, but do try to know when to be in full defense mode and when not to be. If you're pulled over, reciting your rights and repeating "am I free to go" when asked "Do you know why I pulled you over?" is likely to result in a huge waste of time for everyone involved.

Choose your battles, folks.

<comment><USER4> No disagreement here. Sometimes you're forced into dangerous situations and must make the best of it. Some excellent advice from the previous director of the ACLU:

BUSTED: The Citizen's Guide to Surviving Police Encounters <https://www.youtube.com/watch?v=yqMjMPlXzdA>

</comment></comment></comment><comment><USER6> This is a serious, ongoing problem. Police assaulting people for photographing them is a DAILY occurrence. The Website "Photography is not a crime" documents this. <http://photographyisnotacrime.com/>

<comment><USER7> Specifically, they have some more details regarding this incident (not at the top since it's several days old): [http://photographyisnotacrime.com/2013/05/10/california- depu...](http://photographyisnotacrime.com/2013/05/10/california-deputies- seize-phones-after-beating-man-to-death/)

</comment></comment><comment><USER8> It's also worth noting that following the incident, the police invaded the homes of the witnesses who recorded the brutality, and proceeded to harass them, without a search warrant, refusing to leave or allow any of the occupants to leave unless they surrendered the video[1].

[1]: [http://www.bakersfieldcalifornian.com/local/x1891153965/Depu...](http://www.bakersfieldcalifornian.com/local/x1891153965/Deputies- video-confiscations-come-under-scrutiny-in-fatal-Bakersfield-beating-case)

</comment><comment><USER9> Beating people death and then intimidating witnesses into handing over evidence sounds like a police state to me.

<comment><USER10> So, organized crime (i.e. 'the mob') is evidence of a police state?

If the US were really a police state this either wouldn't be news (it happens all the time), or it wouldn't be allowed to be on the news.

<comment><USER9> I think there are many little police "fiefdoms" in the US. Bakersfield itself sounds like one.

</comment></comment></comment><comment><USER11> I'll really love the day when everybody's photo and video services automatically upload to the cloud, so that this kind of evidence can't disappear by force of currupt cops. G+ auto-uploads all my pics and video, I think some other services do this as well. This is mostly a personal feature, but if my phone is ever seized during something like this, the evidence will still be in my control and not theirs.

</comment><comment><USER12> It seems like one of the common things going on right now is the confiscation of the cellphones.

Are there any apps that take video and then immediately upload it to youtube or (better) a password protected site for later retrieval?

</comment><comment><USER12> CATO institute maintains a website with police misconduct news from across the USA: <http://www.policemisconduct.net>

</comment><comment><USER13> This story is disturbing on a number of levels. I'd be very interested in understanding what the law says about the general subject of making recordings of police activity in general.

Could a lawyer on HN explain the the current legal framework surrounding making video recordings of police activity? What are our rights? Can they confiscate equipment? Can they threaten and bully witnesses as reported in this article? Can they go as far as entering your home and, effectively, imprison you?

If one were to make such a recording, what are the five words you can say to a police officer that --assuming he is not a criminal with a badge-- would cause him to back off, leave you alone and not attempt to confiscate your property?</comment>


Complicated Mechanisms Explained in simple animations - <AUTHOR> http://mytechnologyworld9.blogspot.com/2010/08/complicated-mechanisms-explained-in.html <comment><USER2> These animations are awesome, little things you've always questioned but never bothered to check.</comment>


Hard Drive Data Sets - <AUTHOR> https://www.backblaze.com/hard-drive-test-data.html

<comment><USER2> At Backblaze, we've done a lot of our own analyses on our hard drives to look at which ones are most reliable, whether temperature affects reliability, etc. However, we kept being asked for the raw data so people could run their own analyses.

This data set releases 500 million data points on 41,000 drives. I imagine you guys here at YCombinator/Hacker News are the ones who'd find this data amongst the most useful. Enjoy and let us know what you find!

<comment><USER3> Your website uses a terrible HTTPS config.

[https://www.ssllabs.com/ssltest/analyze.html?d=www.backblaze...](https://www.ssllabs.com/ssltest/analyze.html?d=www.backblaze.com)

No PFS, weak RC4, TLS 1.0 only, and SHA1.

It's not much effort to fix these, really. It makes me question the security of your product.

<comment><USER4> We got a B! That's above average! Totally not "terrible". Truth is the website and the service itself are fairly different, but I can tell you that we have a lot of folks using, lets say..."older", browsers that access our site, and so we try to make sure that they can still access their accounts - though we're constantly monitoring for ways to make it better. A lot of folks that use us have older operating systems and that hampers us a bit.

<comment><USER5> Even though it stops folks with updated browsers from accessing your site?

[http://i.imgur.com/3GCKrzr.png](http://i.imgur.com/3GCKrzr.png)

<comment><USER6> Brian from Backblaze here. Which browser was that? We often test with Mac/Windows and Safari/Chrome/IE/Netscape/Opera, etc. It all seems to work here. Did you tweak any browser settings or are you running stock?

<comment><USER7> Unable to Connect Securely

Firefox cannot guarantee the safety of your data on www.backblaze.com because it uses SSLv3, a broken security protocol. Advanced info: ssl_error_no_cypher_overlap

Firefox 35, rc4 disabled

As far as I understood you should not (especially not only) use rc4. [https://en.wikipedia.org/wiki/RC4](https://en.wikipedia.org/wiki/RC4) even cloudflare is trying to get used of rc4. [https://blog.cloudflare.com/killing- rc4/](https://blog.cloudflare.com/killing-rc4/)

> Fast-forward to 2013 and attacks on RC4 have been demonstrated; that makes > the preference for RC4 problematic.

<comment><USER8> Looks like they killed 3DES, leaving only RC4.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> If you haven't already come across Backblaze's series of blog posts based on these data sets, they're worth reading. Invaluable in helping me make an HDD purchasing decision and full of well presented data.

[https://www.backblaze.com/blog/best-hard- drive/](https://www.backblaze.com/blog/best-hard-drive/)

<comment><USER10> Way better than Tom's Hardware, et al.

</comment></comment><comment><USER11> Thanks for this!

I'd be interested in whether shucking drives from external enclosures has any noticible effect on drive life. But the data doesn't seem to capture whether the drivers were shucked or not?

Is that something Backblaze has investigated? Or is the need for drives such that it doesn't matter if shucking does cause shorter life?

<comment><USER2> The tracking on that wasn't easy to align with these data, but from what we've seen the shucked drives seemed to perform similarly. At this point, the percentage of shucked drives in the data set is fairly small.

</comment></comment><comment><USER12> I merged the two years of data into a single R data file for convenience:

[http://pyrovski.github.io/backblaze_data/](http://pyrovski.github.io/backblaze_data/)

</comment><comment><USER13> Nitpicking: It seems you might have an issue with font loading - for me (Firefox on Linux), it reverts to font-weight 100, making the text (which is missing <p> tags, by the way) almost completely unreadable.

Fig A.: [http://i.imgur.com/9rLQwQQ.png](http://i.imgur.com/9rLQwQQ.png)

<comment><USER6> Brian from Backblaze here.

I keep complaining to the visual designer about this, I can't figure out why this is so hard to fix. What's really strange is it often looks GREAT in some web browsers nobody would ever use (IE) but in Chrome on Windows the lower case "g" characters are almost unreadable and disappear.

If only somebody knew how to fix this?

How did you detect it was missing < p > tags? Is there a tool the designers could error check against to see this error?

<comment><USER13> > How did you detect it was missing < p > tags?

Just opened it up in the inspector in Firefox, no black magic here ;-)

I would definitely look into your font names - it tells me that "Lato- Hairline" is used as: "Lato" and "Lato Regular" is used as: "@font-face:Lato". So perhaps the issue is that Lato-Hairline is the font-weight = 100 and Firefox picks it over the other one, only finds the single font-weight and sticks with it?

Just a guess though, webfonts can be weird. For instance: For Chrome, it can depend on what version you use. Just today I ran into a font rendering bug similar to this one where Chromium versions 37&38 had their font-weights switched so that 300 ended up as 500 and 500 was also picked for "normal". So the bug report "all fonts are bold and it looks terrible" resulted in "CANTFIX old Chrome be weird", basically.

<comment><USER6> Cool, thanks! I have forwarded the info, it's actually been driving me slightly bonkers. The designer uses a Macintosh, but my primary development box with a 30" monitor happens to be BOTH Macintosh OR Windows (KVM switch) and when I see our blog in Windows it looks terrible.

</comment></comment></comment></comment><comment><USER7> @brianwski [Offtopic] Is backblaze going to implement delta copy or something similar in soon future? The last time I checked it definitely didn't. This becomes a real issue if I'm working on bigger binary files, since backblaze is syncing the whole file again - instead of only it's difference... PS: Found this interesting comparison of backup services: [https://en.wikipedia.org/wiki/Comparison_of_online_backup_se...](https://en.wikipedia.org/wiki/Comparison_of_online_backup_services)

<comment><USER6> We do transmit "changes" to large files in 10 MByte chunks. In other words, if 1 byte changes in a 50 MByte file it SHOULD only transmit one single 10 MByte chunk.

The absolute worst case for Backblaze is if you insert a single byte at the start of a large file. This "shifts" the entire file along by the one byte, effectively changing every single 10 MByte chunk.

The BEST case is if you append a single byte to a large file, because the final chunk then is probably less than 10 MBytes.

I actually thought we would be working on that area quite a bit over the years but it kind of worked well enough. :-) Most people don't edit large files, with the exception of Outlook.pst files, we see those appear as bandwidth burners.

<comment><USER7> Thanks for your reply, brianwski. That's seems fair enough.

</comment></comment></comment><comment><USER14> This is very much appreciated:

1\. As mentioned by others, there really is very little data on HD failure rates.

2\. When you first published your blog on failure rates across HD brands/models and SMART attributes many, myself included, suggested it might be more illuminating as a predictive modelling exercise. This data allows others to do that now, which is great!

</comment><comment><USER15> as someone who made previous comments on backblaze data analyses posted on HN, i wanted to say thanks. this is fantastic, and i'm looking forward to digging into these data! and even though i share some of the same sentiments from other commenters, i'm sorry you've gotten so many bike shed remarks from other commenters.

<comment><USER4> Enjoy ;-)

</comment></comment><comment><USER16> Releasing this data is a real service, thanks.

I'm unable to explain the plethora of comments nearby about peripheral issues. Weird.

<comment><USER4> No worries! Glad you like our release! We don't mind the peripheral stuff, we're over like -> [http://i.imgur.com/MYHLwt7.gif](http://i.imgur.com/MYHLwt7.gif)

</comment></comment><comment><USER17> thanks for sharing this! A few quick questions:

\- Do you guys do any precise prediction on if a particular drive will fail soon and replace it?

\- I notice a lot of sparsity in some rows, that is different than a 0 in that field I assume? Does that mean anything else interesting?

\- Also under the "inconsistent fields" section you say "drive manufacturers don't generally disclose what their specific numbers mean," can you give a hint as to one of the drive models that has a minimally sparse smart readout and has information available from the manufacturer on what those smart numbers signify?

I figure if anyone has collected the references on what the metadata means, and for which models it is available, it's you guys :)

<comment><USER6> I'll try to get the datacenter techs to answer tomorrow, but here is my best off the cuff attempt:

> predict if a drive will fail

We have some heuristics (high numbers of time outs and high remapped sectors), but in the end most failures are sudden and catastrophic. It is more like statistical tendencies, the most obvious one being drive age.

> sparsely in rows

Others have noticed, I have to ask the OTHER Brian (Brian Beach did the lion's share of this drive stat collection and presentation).

> its you guys

Aww shucks. :-) But remember, we do this as a guide for ourselves, but we spend most days working on backup features and scaling, we don't have a lot of extra time. That's why we sending this data out there, some smart grad student or PhD in Xerox PARC can hopefully figure out some good stuff we missed! Besides, I don't think math and statistics are our strength, we just happen to be sitting on one of the world's larger stock piles of spinning drives with access to the computers with scripts. :-)

</comment></comment><comment><USER18> Minor nitpick: using LZMA to compress large text files like this before distribution is normally better; here 7z is LZMA, zip is DEFLATE:

        739M    2013_data
        37M     2013_data.7z
        78M     2013_data.zip

Using [1] for reference, if the download speed is less than ~20MB/s, LZMA is faster than DEFLATE. Though, the data there is a bit less compressible than these csv files, so the break-even point for transfer rate would be higher here; even so, in my case, the download speed was much slower than 20MB/s.

1\. [http://richg42.blogspot.com/2015/01/parallelized- downloaddec...](http://richg42.blogspot.com/2015/01/parallelized- downloaddecomp-with.html)

<comment><USER6> Disclaimer: I work at Backblaze.

We tend to favor ZIP as a company because with no additional tools on all platforms (like Macintosh and Windows) it unpacks. No additional technology other than what the manufacturer provides.

In this case, we could provide the raw data in several formats in case bandwidth is a problem, plus I think we should provide the SHA2 or md5 of the resulting package just in case you are wondering if you got the correct download or whether somebody has messed with the contents.

<comment><USER19> Windows has the 7zip program which handles lzma just fine - it's overall a better program than zip anyway.

<comment><USER20> He said provided by the manufacturer by default, not something the user has to install themselves.

</comment></comment></comment></comment><comment><USER21> Nice. Glad to see more info out there for people to see and use. Backblaze has done a great service for everyone including the hard disk industry.

</comment><comment><USER22> I'm really looking forward to playing with these; thanks for releasing them, especially since there is so little failure data out there.

</comment><comment><USER23> This is a great resource, Thank you!</comment>


GM, Chrysler seek billions more, to cut more jobs - <AUTHOR> http://biz.yahoo.com/ap/090218/autos_bailout.html <comment><USER2> Ford will ride this out, I'm not so sure about GM and Chrysler, they may be beyond salvage.

The Chrysler/Fiat deal was quite telling, essentially a good chunk of Chrysler changed ownership just for the right to sell Fiat under the Chrysler label.

Fiat is arguably the European car brand with the worst quality image, sure their cars are small and economic but that's not all there is to a car brand.

The fact that Chrysler seems to value itself at '0' is quite an eye opener, and if the news is any indication GM might find itself in Chinese hands after all, with or without congressional approval simply because they will be debt so much with their suppliers that they'd have to change ownership or shut down.

Scary times to be in the auto industry or in any part supplying to or dependent on the auto industry.</comment>


Are iWatch and the New Apple TV Just One Product? - <AUTHOR> http://www.volleythat.com/why-not-combinator-podcast/2014/2/5/iwatch-tv

<comment><USER2> Tv is a social experience, not a personal one like those covered by the iPhone. Is everybody in my house going to need a watch to watch the tv? Plus it would make no sense for them to reduce the target audience for the new Apple Tv. At best there will be a Remote app on the watch.

<comment><USER2> My crazy prediction is that the iWatch will be round.</comment></comment>


Nokia To Acquire Dopplr - <AUTHOR> http://www.techcrunch.com/2009/09/23/nokia-to-acqure-uk-startup-dopplr/ <comment><USER2> >> " The site has never grown to huge usage, but core users are passionate about the service"

I never really understand how these things manage to sell for so much, having so few users.

>> "Dopplr cofounder and CEO Marko Ahtisaari was previously the Director of Design Strategy at Nokia."

Oh... I see...

<comment><USER3> Marko Ahtisaari's primary credential is that he's the son of former Finnish president (and Nobel Peace Prize laureate) Martti Ahtisaari.

Dopplr always seemed like a startup that's been tailor-designed for a Nokia acquisition exit. Glad to see it worked out for them.

</comment></comment><comment><USER4> Dopplr's kind of cool, but I'm still looking for the right thing:

I travel occasionally, and in reality, it's not my circle of friends that needs to be informed, it's the people that I could potentially meet somewhere. For instance, I'm part of Debian (although I really ought to officially retire) and the Apache Software Foundation. There are lists where I can mention that I'm going to be somewhere, and more often than not, it turns out there's someone from there who is happy to meet up. Or the other way around: when people visit Padova (or wherever I happen to be living), I'd be happy to go out and chat about whatever topic we have in common. I want something that lets me get in touch, in a casual and no obligations way, with people who I have something in common with. I suppose that it's never going to be perfect because you can't force all the people from various lists to sign up for some service, but I think it could be improved.

<comment><USER5> Hi David -- There are a few sites like that. You could try travbuddy.com if you are interested in meeting travelers by location or showing them around your hometown, although it has less of a tech slant. couchsurfing.org has more of a backpacking focus, but they also have regular meet-ups around the world.

</comment></comment><comment><USER6> As Om Malik said [http://gigaom.com/2009/09/23/dopplr-commits-hara-kiri- sells-...](http://gigaom.com/2009/09/23/dopplr-commits-hara-kiri-sells-to- nokia/) \-- this kind of feels like death for Dopplr. Can we name a great Nokia web service or software?

<comment><USER7> I'm hoping mixing dopplr's well designed site with Nokia's resources will create a powerful site, but this will probably lead to the death of dopplr.

</comment></comment><comment><AUTHOR> I'd love to know what caused so many high profile entrepreneurs to get involved with Dopplr. Hoffman, joshu, Saul Klein, Martin Varsavsky.

<comment><USER8> I imagine, as people who travel a lot, they found the service extremely useful. It's also a really classy service, and the founders were well almost certainly known to the investors already.

<comment><USER9> Exactly.

I'd been thinking of wanting something like this (I thought of it as a "social network for airports") for a while, so when I heard about it I was interested.

I would hardly call myself "high profile" BTW.</comment></comment></comment>


Stripe Cloud Module for Parse - <AUTHOR>

As we're building our mobile infrastructure over Parse, we love the cloud modules so much we decided to 'rearrange' the node-stripe module for a parse-stripe module. The base code is simple but it allows you with both to process credit cards in your iOS app! Check it out:
https://github.com/vfloz/parse-stripe
Thanks! <comment><USER2> Clickable <https://github.com/vfloz/parse-stripe></comment>