W3C HTML JSON form submission - <AUTHOR> http://www.w3.org/TR/html-json-forms/ <comment><USER2> Let me say first of all that I'm glad they're working on standardizing this. When making REST APIs, I find HTML form scaffolds incredibly useful, but it means that you probably have to accept both JSON (because JSON is reasonable) and occasional form-encoding (because forms), leading to subtle incompatibilities. Or you have to disregard HTML and turn your forms into JavaScript things that submit JSON. Either way, the current state is ugly.

Here's the part that I don't particularly like, speaking of subtle incompatibilities:

        EXAMPLE 2: Multiple Values
        <form enctype='application/json'>
          <input type='number' name='bottle-on-wall' value='1'>
          <input type='number' name='bottle-on-wall' value='2'>
          <input type='number' name='bottle-on-wall' value='3'>
        </form>

        // produces
        {
          "bottle-on-wall":   [1, 2, 3]
        }

I've seen this ugly pattern before in things that map XML to JSON. Values spontaneously convert to lists when you have more than one of them. Here come some easily overlooked type errors.

I don't know of any common patterns for working with "a thing or a list of things" in JSON; that kind of type mixing is the thing you hope to get away from by defining a good API. But all code that handles HTML JSON is going to have to deal with these maybe-list-maybe-not values, in a repetitive and boilerplatey way.

I hope that a standard such as this will eventually be adopted by real-life frameworks such as Django REST Framework, but I also hope that they just reject the possibility of multiple fields with the same name.

<comment><USER3> PHP handles this by having lists like this by requiring you to use an I put name like "bottle-on-a-wall[]". The brackets indicate that it should be a list. I don't hate this convention...

<comment><USER4> the only problem with the bracket syntax is when it comes to nested things

            <form enctype='application/json'>
              <input name='wow[such][deep][3][much][power][!]' value='Amaze'>
            </form>

            // produces
            {
                "wow":  {
                    "such": {
                        "deep": [
                            null
                        ,   null
                        ,   null
                        ,   {
                                "much": {
                                    "power": {
                                        "!":  "Amaze"
                                    }
                                }
                            }
                        ]
                    }
                }
            }

<comment><USER5> What's the problem with that? If it's deeply nested, then it's deeply nested, no matter what.

<comment><USER6> It's pedantic, but it's a tad clunky now: I'd use something like "wow/such/deep[3]/much/power/!" to differentiate child nodes from array indexes, and also strongly advise against a node named "!" on principle. Of course then you'd say "but I want '/' in my node name!", and then you get to bikeshed an escape sequence, but you'd need that anyway for a node name with '[' or ']' in it.

However, what they've done is workable if all the browser vendors implement it.

<comment><USER7> square brackets are a reasonably common way to access data in an hash-like object. both Javascript (objects) and PHP (associative arrays) use/allow square brackets for this.

</comment></comment></comment></comment></comment></comment><comment><USER8> In fairness, you have to look at how standards get somewhere - this is an editor's draft which is a starting point of an idea rather than a done deal. Don't be surprised if the final product winds up being significantly different than this - even better, get involved in the conversation to make it what we need. That's not to pour cold water on it: It's good as it is, but there are changes which potentially help explain the magic of participating in form encoding and submission which may be better and allow more adaptation and experimentation over time.

</comment><comment><USER9> Why such an emphasis on "losing no information" when the form is obviously malformed?

You need only to look at the crazy ways in which MySQL mangles data to realize that silently "correcting" invalid input is not the way to go. The web has suffered enough of that bullshit, we seriously don't need another. Example 7 (mixing scalar and array types) gives me shudders. Example 10 (mismatched braces) seems to have a reasonable fallback behavior, though I'd prefer dropping the malformed field altogether.

If the form is obviously malformed, transmission _should_ fail, and it should fail as loudly and catastrophically as possible, so that the developer is forced to correct the mistake before the code in question ever leaves the dev box.

Preferably, the form shouldn't even work if any part of it is malformed. If we're too timid to do that, at least we should leave out malformed fields instead of silently shuffling them around. Otherwise we'll end up with frameworks that check three different places and return the closest match, leaving the developer blissfully ignorant of his error.

While we're at it, we also need strict limits on valid paths (e.g. no mismatched braces, no braces inside braces) and nesting depth (most frameworks already enforce some sort of limit there), and what to do when such limits are violated. Again, the default should be a loud warning and obvious failure, not silent mangling to make the data fit.

This is supposed to be a new standard, there's no backward-compatibility baggage to carry. So let's make this as clean and unambiguous as possible!

<comment><USER10> That's not the Web way. The Web is the lowest common denominator, all that talk of "correctness" goes over the head of most Web Developers.

</comment></comment><comment><USER11> I don't agree with Example 9, we should use data uri scheme for file content

        "files": [{
          "name": "dahut.txt",
          "src": "data:text/plain;base64,REFBQUFBQUFIVVVVVVVVVVVVVCEhIQo="
        }]

[http://en.wikipedia.org/wiki/Data_URI_scheme](http://en.wikipedia.org/wiki/Data_URI_scheme)

<comment><USER12> 1\. Other form encoding types have discrete MIME type fields.

2\. While data URIs are awesome, it forces you to process that URI in some way (parse, regex, whatever) just to get the MIME type. Also, this forces 13 bytes of redundancy every time.

</comment></comment><comment><USER13>
        {
          "name":   "Bender"
        , "hind":   "Bitable"
        , "shiny":  true
        }

Who puts commas at the _start_ of a continuing line? What good could that possibly do?

<comment><USER14> It lets you comment out a line without having to remove the trailing comma from the previous line. That'd be useful if JSON had comments.

I've seen people do this in the SELECT portion of SQL queries too.

Personally, I hate this.

<comment><USER15> > It lets you comment out a line without having to remove the trailing comma > from the previous line

That would only be an advantage above comma at the end on the last line. It really only moves the problem from the last line to the first one. Now you can't comment out the first line without removing a comma...

<comment><USER16> In the comma-first method, adding a new element at the end produces a one mine diff. But when doing comma-last method, then adding a new element to the list gives a two line diff.

It can make resolving merges just a little bit easier.

</comment></comment></comment></comment><comment><USER17> I'm not sure whether to be heartened or concerned that the W3C is referencing the doge meme in its specifications... see Example 6.

<comment><USER18> Concerned. Memes are in-group signalling one notch above the crudest kind such as football chants, a few notches below the more sophisticated kind like quoting Shakespeare, but all ultimately with the potential to exclude and confuse - which is definitely the opposite of what a technical spec should be trying to do.

<comment><USER19> I don't see why would this exclude or confuse. It's essentially an in-joke, and shouldn't affect anyone reading the spec who is unaware of the meme.

I'm not a fan, but I don't think we should make it out to be more than it really is.

</comment></comment></comment><comment><USER20> It amazes me that we're now at the point of standardizing sticking array references inside strings and yet we're still not having a serious discussion about what comes after HTML.

<comment><USER21> It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML. HTML is what it is, nothing else is what HTML is, and HTML is going to be around a good long while.

<comment><USER22> _It amazes me that you think we could have a serious discussion about what comes after HTML when essentially nobody is seriously considering replacing HTML._

Of course we are. There are numerous new technologies competing to replace the role we have shoe-horned HTML into playing -- look at all the different templating technologies now in development, for example, and things like Web Components. There are also numerous technologies for marking up semantic content and/or styling such data for presentation.

The only thing that isn't changing right now is that we're still stuck with eventually reducing these alternatives to plain HTML for display in browsers, which is about as good an idea as insisting we reduce all styling to CSS and all programming to JavaScript. It's a historical accident, it's resulted in widespread dependence on tools that are nowhere near fit for the purposes they are now asked to serve, but there is so much momentum in the industry that building tools to accommodate the weaknesses as well as possible is the preferred strategy over completely starting over. See also: Almost everything about programming ever.

<comment><USER20> Fully agreed. A low(ish)-level, non-JS API to the sea of DOM "primitives" inside blink/gecko/webkit/etc. suitable for targeting in an FFI-like manner by any language is the standard I'd like to see. We don't need 3 languages: it's all there in C++ classes and C structs.

I've been writing a lot of ClojureScript/React lately and with that I only really touch HTML to include CSS and scripts. It's pretty glorious, highly productive, and makes a very strong case for opening up lower levels to allow new paradigms to evolve - with this set-up, HTML and JS only get in the way.

The browser is now (almost) an OS in a VM and, imho, the sooner we start treating it like that the better.

</comment></comment></comment></comment><comment><USER23> Seems pretty decent. Also neat that the nesting style could be repurposed to support nested structures in regular form-encoded HTML forms.

Main limitation on _actually_ being able to use this is that `GET` and `POST` continue to be the only supported methods in browser form submissions right now, so eg. you wouldn't be able to make JSON `PUT` requests with this style anytime soon.

Might be that adoption of this would swing the consensus on supporting other HTTP methods in HTML forms.

</comment><comment><USER24> They're still working on XForms after 10 years [http://www.w3.org/MarkUp/Forms/](http://www.w3.org/MarkUp/Forms/)

<comment><USER25> Isn't that kind of like saying "They're still working on HTML after 23 years"? Technically you're right, but version 1.1 of XForms was completed and published over 5 years ago.

That said, XForms is dead AFAIK, and that's not a bad thing.

<comment><USER24> Yeah, my point was more along the lines of they've been working for 10 years and gotten near zero adoption. Not saying it will fail again for sure, but if this had value, XForms would have found it. URL-encoded POST data works just fine.

<comment><USER26> XForms has a bigger scope and is connected to XHTML. Two good reasons why this might succeed where XForms failed.

</comment></comment></comment></comment><comment><USER27> The latest release of my jarg[0] utility supports the HTML JSON form syntax. Writing out JSON at the command line is tedious, this makes it a little nicer. The examples from the draft are compatible with jarg:

        $ jarg wow[such][deep][3][much][power][!]=Amaze
        {"wow": {"such": {"deep": [null, null, null, {"much": {"power": {"!": "Amaze"}}}]}}}

[0]: [http://jdp.github.io/jarg/](http://jdp.github.io/jarg/)

</comment><comment><USER28> Kind of nice, basically turns form submission into a bare-bones API call.

<comment><USER24> Which they pretty much already were. The only value I can imagine this adding is a way to encode forms with nested structure.

<comment><USER4> The changes they make solve the problem of corner cases submitting weird input to an API that expects only JSON

In 2014, I think this is a good idea.

It also solves the issues with ambiguous syntax surrounding arrays of values.

</comment></comment></comment><comment><USER29> Am I the only one who is worried about the fact that this is exponential in size?

      <input name="field[1000000]">

Will generate a request that is ~5MB.

<comment><USER19> I don't see why that should be worrying. What's the scenario you're foreseeing?

</comment></comment><comment><USER30> The JSON-based file upload would be nice (AFAIK there's not great way to do this ATM, but I haven't looked in over a year). The rest seems pretty weak-tea though. I can see multiple issues with more defined type (e.g. numeric rather than string values, null rather than blank string), but without dealing with that stuff, this seems of extremely limited utility.

<comment><USER31> It's nice for small files but base64 really is inefficient. I think it is still used in mails, but really, you should use it only when you control all the usages that will be done with it.

</comment></comment><comment><USER32> Submitting files with this form encoding is of course going to have the base64 overhead, but otherwise this looks great!

<comment><USER33> Yea this makes me wish there was a better way to deal with this. JSON is popular because it's simple, but as a result sucks for a bunch of use-cases.

<comment><USER34> I'm mobile so don't have a good way to just test this myself... Any idea how good/bad base64+gzip is (ie gzipping the json before submitting it)? If it's within a few percent then this probably isn't a bad solution!

<comment><USER35> The browser doesn't gzip _requests_ by itself, only the server does so with the _response_ if the user-agent (including browsers) states that it supports such content encoding. Of course you can implement gzip in JavaScript, but if you do that, you can already mangle the request and send the file to the server without Base64 encoding.

</comment></comment></comment></comment><comment><USER36> A discussion about the implementation of the spec in jquery. It started on June 21

[https://github.com/macek/jquery-serialize- object/issues/24](https://github.com/macek/jquery-serialize-object/issues/24)

</comment><comment><USER37> How is it solving CSRF JSON problem? [http://homakov.blogspot.com/2012/06/x-www-form-urlencoded- vs...](http://homakov.blogspot.com/2012/06/x-www-form-urlencoded-vs-json-pros- and.html)

</comment><comment><USER38> A new standard for referencing a point in a JSON object? I wonder if they considered RFC 6901 and rejected it.

I personally prefer this new square bracket notation, but being a standard already gets more points.

<comment><USER23> JSON Pointer isn't quite the same thing.

<comment><USER38> I humbly disagree. JSON Pointer is a syntax for specifying a location in a JSON object. Multiple form items with JSON pointer strings as names would map to the equivalent of a number of add operations in a PATCH call that start with an empty object.

</comment></comment></comment><comment><USER39> Wow, W3C at it's best again. Non-modular, non-negotiable, JSON it is, take it or leave it. Well fuck you W3C. Base64 encoded files? Seriously? What if my app workes better with msgpack encoded forms? Or with XML encoded? So you're going to support one particular serialization format, quite a horrible one, but that's subjective and that's the whole point. Every app has different needs and you should spec. out a system that is modular and leaves the choice to the user, even for the price of "complicating things".

<comment><USER23> How would you deal with rendering arbitrary form encodings in the browser? A proposal adding support for form submission of _arbitrary_ encodings could be valid, but it'd have to just be a single form input with the data included verbatim.

This proposal allows regular HTML forms with multiple input elements, but submitting over JSON. I can't see how you could define that for arbitrary encodings without first defining how the form fields map to the encoded data for all the encodings you'd want to support.

<comment><USER39> Eg: By referencing an encoder function using the standard on* attribute. Could be called onbeforesubmit=encodeMsgpack. This function would take a JS object, generated according to the W3C's JSON form spec, and return a pair of [string, arraybuffer]. String being the MIME content type, and arraybuffer containing the request body.

<comment><USER19> If you're going to run custom JS code, why not simply submit it through JS HTTP requests? What have you gained by this new API?

</comment></comment></comment></comment><comment><USER40> Guessing that it's interesting when using an uniform endpoint for both forms and js-driven requests.

</comment><comment><USER41> Can we just get rid of HTML and replace it with JSON while we're at it?

<comment><USER6> I don't know if there's a proper name for this ability, but neither JSON nor YAML allow you to embed child tree nodes inside of node values. This ability requires named end tags. Example:

This is bold text.

        "p": "This is ... uh ... nevermind."

You could make a compelling argument that you shouldn't do this (separate block level and inline elements into separate encodings), but remember that even the relatively minor HTML->XHTML movement to put a bit of sanity into single-use tags like
 ->
 failed miserably.

<comment><USER42> Nodes have multiple children. In this case, you can split the
's children into three: a "text node"; a  node; and another text node. You'd end up with something like this:

        {
          p: [
            { text: 'This is' },
            { b: { text: 'bold' }},
            { text: 'text.'}
          ]
        }

Not that I don't agree with you -- my suggestion is pretty messy and doesn't even go into how we'd deal with tag attributes -- but it's doable.

<comment><USER10> This has to be pre-processed somehow, if people don't like writing HTML by hand, consider writing that.

<comment><USER6> Yeah, and that's not really equivalent HTML either. That's more like:

          <text>This is</text>
          <text>bold</text>
          <text>text.</text>

(which is a lot easier for a machine to parse, at least.)

JSON and YAML are great for what they do: data serialization, but they're just not appropriate choices for text markup. You have to use the right tool for the job.

There was a time when the industry wanted to cram 100% of everything into XML, and that gave us XSLT, XAML, SOAP, etc. We don't want to go back to that, either.

Personally, I'm most fond of an extended Markdown syntax to replace HTML. But I'm not going to hold my breath waiting on web browser vendors to agree on such a syntax, so instead I have my HTTP server do the conversion to HTML for me.

But if you had to force it into JSON, then I would suggest using a different markup for inline elements, eg:

        html
          body
            p: "This is [/italic/] text."
            p: "This is [[google.com => a hyperlink.]]"

</comment></comment></comment></comment></comment><comment><USER43> > wow[such][deep][3][much][power][!]

And there goes my interest for this submission. Don't use overused memes in a submission. Liking the idea though.

<comment><USER44> I enjoyed this. I also liked the Bender reference.

It reminded me of that show that makes me laugh on Netflix.

It also illustrated the point that he was trying to make. I prefer warm examples, rather than ones using book titles.</comment></comment>


Network Solutions renames their services for added obscurity - <AUTHOR> http://www.jgc.org/blog/2009/08/network-solutions-renames-their.html <comment><USER2> Unfortunately this is becoming far too common. The marketing team thinks "hey we need to have a 'proper' name for this product" and they end up alienating and confusing their user-base. 99% of customers know they they want to register a domain and not buy a nsWebAddress.

In my experience this happens when a company starts hiring marketing and sales people that are so far removed from the typical buyers and they eventually have no language in common. It's also a good indicator of a business that is doomed in the not too distant future.

<comment><USER3> But NS's target market is the other 1% who are too unsavvy to know what a domain is, or that Netsol are the most legendary shitbags on the internet. They don't want those customers googling the name of the product and finding out that it can be bought elsewhere. Marketing knows what they're doing.

</comment></comment><comment><USER4> Epic MBA WTF.

<comment><USER5> As an MBA-in-training I resent that! I would _NEVER_ rename services to something that asinine. Although I'm not in marketing... ;)

</comment></comment><comment><USER6> The NS suffix is even more confusing for Cocoa programmers.

[[nsWebAddress alloc] initWithDomain:@"example.com"]

<comment><USER7> Worse, the lowercase "ns" prefix is used by Mozilla. E.g. <https://developer.mozilla.org/en/nsString>

</comment></comment><comment><USER8> Who uses this overpriced Network Solutions nowadays? I needed to work with it for a client, registering overpriced domain names through them is a huge pain in the ass as they try to sell you all this other nonsense. It's really one long road with obstacles to get it only registered.

<comment><USER9> People who make registrar decisions based on advertisements, which is a fair amount of non-tech people.

</comment></comment><comment><USER10> how precisely can they trademark "Design/Develop" ?

</comment><comment><AUTHOR> They sent me a message about one of my domains which contained the following text "nsWebAddress .COM". I couldn't actually parse that and figured their email system must have been misconfigured.

</comment><comment><USER11> now your tech support calls can be as fun as ordering coffee at starbucks.

"hi, i'm calling on behalf of customer xyz. i need to have their domain xyz.com unlocked."

"you mean their nswebaddress, sir."

"no, i mean their domain name. xyz.com."

"a domain is an nswebaddress, sir."

"then why don't you just call it a domain name? so, can you unlock it?"

"i can unlock their nswebaddress, sure."

<comment><USER12> The Starbucks naming conventions drive me crazy because of the fact that they all mean, essentially, "big." So it's impossible to remember which "big" you want for a medium-sized coffee!

<comment><USER13> They always humor me when I order 'small'/'medium'/'large'.

But also, did you know there's a secret even-smaller 'short' size? See:

<http://www.slate.com/id/2133754/>

I don't think there's an "animal style" cappucino, though.

</comment></comment></comment><comment><USER14> Notice how all the new terms are trademarked. That must have played a big role in the decision.

<comment><USER15> That's exactly it. You can't trademark "Sci-Fi" and you can't trademark "Domain", but these things, you can.

[http://www.wired.com/underwire/2009/07/sci-fi-channel- reboot...](http://www.wired.com/underwire/2009/07/sci-fi-channel-reboots-as- syfy-with-eye-on-expanding-empire/)

</comment></comment><comment><USER16> what are they going to call their whois service?

nslookup?

</comment><comment><USER17> FYI they also run namesecure.com, but obscure it pretty well. The interface sucks and the service sucks even more. But it is cheaper than their normal Network Solutions portal.

I switched to namecheap.com instead.</comment>


Apple rewrites app store economics - <AUTHOR> http://www.ft.com/cms/s/0/01a151fc-0b8b-11e5-8937-00144feabdc0.html

<comment><USER2> Sadly behind a subscription or paywall.

<comment><USER3> Free signup. Here's the gist of it:

"Apple is planning a departure from the pricing formula that has defined the economics of digital media for a decade, which would cut the 30 per cent fee music, video and news companies pay on subscriptions through its App Store"</comment></comment>


RSA Keys Can Be Harvested with Microphones - <AUTHOR> http://www.theregister.co.uk/2016/06/04/sidechannel_encryption_theft/ <comment><USER2> keep your bitcoin safe, kids :)</comment>


Looking for a Co-Founder? - <AUTHOR>

A friend of mind runs this, and I think it would benefit a lot of people looking for cofounders.
--
Ready to Meet Your Co-Founder?
FounderDating brings together super talented entrepreneurs with different backgrounds and skill sets to start innovative new companies.  We help you find co-founders with complimentary skill sets. This is NOT a meetup, it's an invite-only event so the people and the conversation are high quality.
Next Event is April 6th, Deadline to apply is April 1st. www.founderdating.com <comment><USER2> I highly recommend it :)

</comment><comment><USER3> Why would 'super talented entrepreneurs' need this to find co-founders?

<comment><USER4> I imagine the intent is to provide a service to "super talented people" who would like to become entrepreneurs.</comment></comment>


Moscow Nginx office under police raid - <AUTHOR> https://o.wzm.me/river/stream/123393 <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=21771144](https://news.ycombinator.com/item?id=21771144).</comment>


IPhone users are suffering from a form of Stockholm Syndrome - <AUTHOR> http://news.cnet.com/8301-17852_3-10414356-71.html

<comment><USER2> Shitty headline grabber from an even shittier consultancy. On my desk I've got a Blackberry Curve, Samsung WM, and an iPhone 3GS. I write and test software for the first two. The last is a new addition that I haven't gotten around to.

The firm has the idea that users are too stupid to know what they like. And since the iPhone is the only option (really?!) then users are obviously delusional. The poster has written a poor headline and should rescind it. No one is being held hostage. Because other makers are still in business then there must be a viable business for them to stay in it. And the goalpost is always moving forward. If I've learned one thing about Apple, execution is their business. If a feature: won't work, is buggy, or too complex they won't implement it. They'll eventually do it, but not at 80%, not even 95% complete.

And finally, I didn't pay for my phone the company did. So this is as close to an objective opinion your going to get. There is no buyers remorse here. I have a cabinet of phones I could use if this one didn't work out. Some of my colleagues have turned in their iPhones and gone back to BBs, WMs, and Nokias.

<comment><USER3> Speaking as a guy who just punted his iPhone for a Droid a few weeks ago, there was definitely part of me who has been saying "Why did I put up with that for so long?" 'It' being the awful call performance (data and apps were great).

I'm sure I'm not the only one... So why DID I put up with it? Part of it might be a love-affair with Apple due to their exceptional marketing and the near mythical status of Steve Jobs.

Consumers aren't stupid-- but I can't imagine how you could think that all of your decisions are rational... Or even most of them. Ever done any A/B testing? Why would an orange button perform 20% better than a blue one?

What about priming studies?

(more thoughts in an old blog post: [http://www.tonywright.com/2007/the-fuss- about-macs-priming-a...](http://www.tonywright.com/2007/the-fuss-about-macs- priming-and-racism/) )

Here's the interesting bit:

Bargh and several colleagues chose a group of undergraduates as subjects and gave them two scrambled-sentence tests. The first test was sprinkled with rude words like "disturb," "bother," and "intrude." The second test was sprinkled with polite words like "respect," "considerate," and "yield."

In both cases, the tests were indiscreet. None of the subjects picked up on the word trend consciously. But it primed them subconsciously.

After taking the five-minute test, students were asked to walk down the hall and talk to the person running the experiment about their next assignment. An actor was strategically engaged in conversation with the experimenter when the students would arrive. And the goal was to see how long it would take students to interrupt.

"Bargh wanted to know if the subjects who were primed with polite words would take longer to interrupt the conversation than those primed with rude words. They thought the subconscious priming would have a slight affect. But the affect was pretty profound in quantitative terms.

The people primed with rude words interrupted, on average, after only five minutes. But 82% of the people primed with polite words never interrupted at all. Who knows how long they would have patiently and politely waited if the researchers hadn't give the test a ten-minute time limit. [Note by Tony: Those damn ethics committees... Milgram would never be able to get away with his experiment today!]"

<comment><USER4> '"Why did I put up with that for so long?" 'It' being the awful call performance (data and apps were great).'

Maybe it was because the data and apps were great?

<comment><USER3> I don't think so. There were virtually no apps on the iPhone that were important to me (though it is a touch faster than the Droid in terms of data speed). My iPhone was, for me, first and foremost a phone. And it was TERRIBLE at that (dropping calls constantly). (note: I'm in Seattle-- from what I understand, it's a problem that's most common in NYC, SF, and Seattle)

</comment></comment></comment></comment><comment><USER5> Perhaps iPhone users accept the limitations because the stuff it does actually do works so well for them?

This explanation, however, doesn't provide a good headline, so obviously isn't plausible.

<comment><USER6> So because it makes a bad headline, it obviously is? It's worth investigating why, in such a feature-driven industry, a product with good marketing but so lacking in features is so popular. We've established that iPhones are locked to a carrier that has the worst customer service ratings in the industry, and that it can't do basic things other smartphones do, like multitask. Yet, it's the gadget to have and continues to fly off the shelves years after its release. I think that's pretty interesting, and simply saying "yeah, it's just _really good_ at making those phone calls" doesn't cut it (considering a 30% drop call rate is considered OK, saying it's really good at making calls would be a stretch).

Listen, I've recommended friends and family of mine get iPhones, and I'm typing this on a Mac. But the best thing you can do for companies you like is call them on their crap. And a lack of basic chat functionality on the iPhone is a sad state of affairs, and no one really seems to talk about it. Apple does some stuff wrong, but they tend to cover it up through marketing. My wife, who used to use an iPhone, just pointed out to me as I was typing this that iPhones are a status symbol, and many people buy them more because they are iPhones than out of any real analysis of the features. Once bought, people want to validate their own decisions, so they'll defend the inferior product. Such is the power of marketing.

<comment><USER7> The iPhone has feature parity or superiority with most other SmartPhones. It seems the goal posts keep moving on features. No one was going to buy the iPhone because:

-No copy & paste -No MMS -No stereo Bluetooth -No third party apps -No video recording -No Flash

Except they did. They bought it and liked it -- many of them bought another one (3G/GS). So it appears to me it's not really a feature-driven industry. It's a usability driven industry. Making a complex device easier to use is more important than offering every possible feature.

<comment><USER8> you have a good point; more features, all other things being equal, means more complexity.

</comment></comment></comment></comment><comment><USER9> Like the first Mac, the iPhone is the first phone good enough to criticize.

Sure, plenty of limitations, but overall, the iPhone completely redefined how well a phone could work, and has massively expanded what people expect from their phones.

To the benefit of users of the iPhone _and_ competing devices alike.

<comment><USER8> See, I still don't get it. I mean, to me, the nokia communicators of 10 years ago look like better devices than the iphone.

But then, I guess most people really like the touch screen interface, and apple (maybe? I wouldn't know. I can't stand touch screens) was the first to get the touch screen right.

<comment><USER7> Maybe the E90 but, come on now, a circa 2001 Nokia Communicator doesn't have 3G or wifi. It has a 66Mhz CPU. It's browser was a bit useless when the phone was released and probably completely incapable of rendering any non-WAP web page today. I don't see how it's even remotely possible to compare the two devices. It would be more apt to compare the 2001 Communicator to a Newton.

<comment><USER8> Yes, clearly I am exaggerating. the 9290 doesn't even have EDGE, so there really isn't a comparison. (I have one on my desk right now, actually. I find the phone aesthetically appealing, which probably says a lot about why I don't "get" the iphone. [1] but without EDGE, at least, it's not particularly practical. The intent of the designers was that you would do dialup, but something changed in the GSM protocol so dialup no longer works, making the phone nothing but a giant sms device and decent offline (and thus obsolete) PDA.

(as an aside, I think the newton is interesting because if it's handwriting recognition was good enough, we'd be seeing handwriting recognition as a dominant input method for PDAs today. The thing is, it wasn't, and by now, even if someone comes up with absolutely perfect handwriting recognition software, too many of us have grown up not knowing how to write. the time when handwriting recognition could have worked is over.)

However, the 9500 was released in '04, and I think it can reasonably be argued that it is as 'advanced' as the first generation iphone. It doesn't have 3g, but neither did the first iphone. it does have wifi, edge, and a /keyboard/ making it a much more useful device, imho, than the iphone. I understand that the keyboard vs. touchscreen debate is subjective, and probably has more to do with what you are used to than anything else, but aside from the touchscreen, I'm not sure how else the iphone is more 'advanced' than the communicator 9500.

Now, if you want to compare modern devices, check out the n900. it's pretty slick. it's got a touchscreen and a keyboard, and the screen is absolutely beautiful, even in full sunlight. Under the covers, it's linux, and it's sold unlocked, so you can play with it. The maemo linux stuff is pretty close to regular linux, so you have a chance of understanding it too. Again, the apple software is better /if it does what you want/ while the nokia hardware is clearly superior, and the nokia software allows you to do exactly what you want /if you know how/.

I'm not saying the iphone is bad- If you have the same needs that apple had in mind when they designed it, it's a really great phone. But I think what they took out was probably more important to that than what they put in. As far as I can tell, apple didn't do anything particularly innovative in terms of features or technology, but they certainly made a lot of users happy. My belief is that part of their success was that they made the interface /just right/ for a certain class of users, by removing the sort of features those users don't want. (unfortunately, I don't belong to that class of users.)

Now, previous nokia communicators were status symbols in other parts of the world, but here, they never were. The iphone was the first smartphone to impact your image positively in the US. I'm the last person you should ask as to why that is, but I will give you my opinion anyhow: the Iphone was the first smart phone that cool people could effectively use.

[1] the thing is big and blocky. It looks as tough as it is. You can drop it, throw it, stick it in your pocket with your keys, and assuming your pockets are large enough to handle it, there's not a problem. I like clamshell designs for this reason.

</comment></comment></comment></comment><comment><USER10> Maybe the article fails to notice that most iPhone buyers are not the typical smartphone (feature-driven) users. The fact it does many things a common smartphone does is just a nice free and welcome extra they did not want.

The iPhone, as it is, appeals to a variety of different user profiles. There are people who buy it for the cool factor, others that buy it because it's from Apple, others that want games, those who get it for the web browsing and still others that buy it as a phone with an integrated iPod. And, of course, those who buy it as a smartphone. The fact it fills all these roles adequately with a nice GUI makes it a top seller.

It may not even be the best seller in any market segment I described, but even being an average seller in a dozen segments can make any marketing exec smile.

</comment><comment><USER11> People will always defend something they buy, ask people similar questions about the limitations in a laptop vs. a desktop, an Xbox 360 vs. Playstation 3, a Lexus vs. BMW, and you will see very similar answers.

This is really a joke of a "research report", it's more like a bad high school paper.

</comment><comment><USER12> Troll Apple users, get web hits, sell ads. Duh.

</comment><comment><USER13> The iPhone is feature poor? How many tens of thousands of apps are there these days? Those improve the functionality of my iPhone infinitely. They kind of seem like features to me.

</comment><comment><USER14> I've only been using Apple products for about 3 years. Currently I have a MacBook Pro and 3GS. The main reason I switched, since most feaures I cared about could be found on multiple platforms, was build quality. It would be hard to deny that the unibody laptops Apple makes are incredibly solid and long-lasting. Same goes for an iPhone with a basic amount of care. The side- effect of this is resale value. Of course the iPhone's resale value is inflated due to the unlocked market, but even the laptops have insane resale value. It's nice to know that when I need to upgrade I can pay for 30%+ of a new model with the proceeds of selling my current one. Go out and pay $2000 for a plastic laptop, use it and abuse it for a year and try to sell it. Paint will be rubbed off, there will be squeaky loose panels, people will only laugh.

Again, these are just my personal reasons for choosing Apple at this time, I am more than willing to give other companies a chance if they can manage to make great hardware to go with their great software. So I really don't feel myself held hostage by anyone but AT&T and I am definitely not in love with them, so no, there is no Stockholm Syndrome here.

<comment><USER8> heh. I am on the other end of that curve; I buy a year old $1500 lenovo ThinkPad X series and I get the keyboard feel I love in a 'just right' sized laptop with reasonably good Linux drivers for $450. Sure, the resale value will be zero, but let's be honest; after 3 years in my messenger bag, anything but a high-end toshiba toughbook is going to be unusable.

</comment></comment><comment><USER15> I liked the iPhone because the features that were lacking at the time were not very important to me, and the features that _were_ implemented are for the most part extremely well done; not because I'm some delusional fanboy.

My needs have changed a bit and so I'm using an Android phone now. But I was pretty happy with the iPhone for quite a while, despite its limitations.

<comment><USER10> It's not because you don't think you are crazy that you are not ;-)

And that's the more perverse thing in this article - it short-circuits any iPhone users' defense because they are all delusional.

<comment><USER15> No, the giant bunny sitting next to me says _you're_ the delusional one.

<comment><USER10> So you see him too...

</comment></comment></comment></comment><comment><USER16> I see what they are saying; but I have a different counterpoint.

I got an iPhone because it looks nice and I figured the apps would be cool. Well it looks nice but the apps, for the most part, don't do much but divert me. There are some I use - but not as frequently as I use the phone, email and calendar features.

I toyed with ditching the phone but now I cant: im totally sold on the phone functionality.. it's the best set up I've ever had.

And there I think is the hook: the iPhone really does _just work_ as a phone. Lots of smart phones never manage that :)

(there are plenty of "wtf" moments... but they havent yet completely frustrated me - which is rarw)</comment>


Via handwriting analysis, scholar discovers unknown Magna Carta scribe - <AUTHOR> http://phys.org/news/2015-09-analysis-scholar-unknown-magna-carta.html

<comment><USER2> That is a level of meticulous detail and analysis that simply leaves me numb. I have nothing but respect for people who can do work like this, I consider it almost magical.</comment>


Ajax Fancy Captcha: Drag & Drop CAPTCHA (jQuery plugin) - <AUTHOR> http://www.webdesignbeach.com/beachbar/ajax-fancy-captcha-jquery-plugin <comment><USER2> Interesting idea, but would this not be relatively easy to crack, given that the problem would basically resume to mapping images to words (i.e. no OCR involved, just a histogram would suffice) ?

<comment><USER3> My thoughts exactly. With the current implementation, you wouldn't even need anything as complex as a histogram, an MD5 dictionary of image files would be fine.</comment></comment>


Making large Python projects painless - <AUTHOR> http://engineeringblog.yelp.com/2016/03/venv-update.html <comment><USER2> _Even though we had pinned all our dependencies (with requirements like package-x==1.2.3), pip would still reach out to PyPI before before deciding which version to pick._

Another solution for this would be to build wheels for all dependencies and invoke pip with --no-index -f [https://url.to.wheels](https://url.to.wheels).

</comment><comment><USER3> So this is basically Conda?</comment>


New Clues in the Target Breach - <AUTHOR> http://krebsonsecurity.com/2014/01/new-clues-in-the-target-breach/

<comment><USER2> A few interesting points on this...

First, breach involved BMC management software that probably costs a bazillion dollars, using what was apparently a default password. It would be good practice for management software vendors to analyze customer configurations for untouched defaults (especially security-related ones) and make it an obvious notification.

Second, it involved compromise of the POS terminals themselves (which would explain why Target had obviously new POS software shortly after the breach). It may have been scraping memory in the terminals.

In general, yikes.

<comment><AUTHOR> The big unanswered question is how the malware was installed on POS devices in 1,700 stores. The configuration and network connections of these machines would typically be rigorously controlled and audited.

Initially it looked like the BMC BladeLogic configuration management tool was compromised, which could be the conduit to the POS devices. The POS already trusts BladeLogic for config changes and patches.

But now McAfee and BMC say the malware was just masquerading as BladeLogic. Sure wish Target would explain what happened so the rest of us can protect ourselves.</comment></comment>


JavaScript Testing Tactics [video] - <AUTHOR> http://blog.testdouble.com/posts/2013-10-03-javascript-testing-tactics.html

<comment><USER2> For anyone that is looking to get better at TDD with javascript, I highly recommend James Shore's webcast site: [http://www.letscodejavascript.com/](http://www.letscodejavascript.com/)

<comment><USER3> Thanks for the plug! :-) I hang out^H^H^H^H^H^H^H^H spend far too much time here on HN and I'm happy to talk about testing JavaScript all day long, if anybody wants to know more.

</comment></comment><comment><USER4> I tried switching to (Iced)CoffeeScript to write tests (using Mocha and Sinon) for a Node app (written in JS). It went something like:

Week one: this is awesome. It's so clean!

Week two: asynchronous stuff is still an utter pain though. Hey, what's this IcedCoffeeScript...?

Week three: Wow, ICS is great. My tests look like Ruby & rspec now!

Week four: ICS produces unholy Javascript and unintelligible stacktraces. I've lost count of how many hours I've lost trying to figure out which line triggered a test to fail. Let's switch back to CoffeeScript and use async.

Week five: Still fed up not being able to identify which line failed at a glance, and have been bitten more than once by CoffeeScript's indentation causing subtle errors, which is easy to confuse if you do any copypasting within `describe` blocks.

Week six: I'm just going back to straight JavaScript. It's a pain but it does the job.

I've since given up on being able to write tests in Node.js with the same elegance/ease as I can with Ruby & rspec.

I still dig CoffeeScript, but now I only use it for client-side stuff. And as for IcedCoffeeScript, that has found a place in my toolbelt for small scripts, where its speed to write and lack of noise are worth the trade off in maintainability.

</comment><comment><USER5> What I wont do: Use a totally different language to write my tests.

<comment><USER6> The term "totally different" is a bit exaggerative here. I hadn't clicked through the slides, but after reading your statement I wanted to see what crazy "totally different" language was being used to test.

Really, a transpiled language isn't much of a stretch.

Edit: Fixed spelling typo.

<comment><USER5> It is a stretch because it has different semantics and behavior. It also means that anyone that comes along to contribute or work on the project that knows JS now has to learn coffeescript and any random details that brings to work on your JS project. This doesn't really make sense to me. Just use JS or CS but both in the same project?

<comment><USER7> I barely knew javascript before I learned coffeescript. Now I know both pretty well as a result. coffeescript compiles to really readable javascript anyway (yes, that's subjective).

I use both in the same project. For example, I have a gruntfile written in javascript. It's easy for me to modify it. The rest of my code is in coffeescript. It's easy for me to modify it.

I think this is a really superficial line for you to draw in the sand. Use the best tool for the job. When you build a house, you end up using more than one tool.

</comment></comment></comment></comment><comment><USER8> Shamless plug: Fed up with there not being a dead simple library for stubbing stuff when writing Javascript tests in Jasmine (I come from the Ruby world), I wrote Why.js. It let's you stub anything and everything, and is optimised for tests written in Coffeescript.

Example:

        why.stub 'User.find', (userId) ->
          { name: 'Bob' }

[https://github.com/lucaspiller/why.js](https://github.com/lucaspiller/why.js)

<comment><USER7> Why (no pun intended) should I use this over sinon?

<comment><USER8> I should probably add that to the readme: I was using Sinon for other stuff (mainly the spies to check stuff is called), and wanted to mock a call to X.Y.Z. This was an external component with it's own tests, so for test isolation it wasn't included in the environment for this test - as such X.Y and X.Y.Z didn't exist. Sinon has the mock function, but you can't call it on stuff that doesn't exist. I guess you could stub X to include Y then stub that to include Z but it seems a bit overkill. Also coming from a Ruby background I'm not a fan of Sinon's quite verbose syntax. So I quickly whipped this up to do what I wanted :)

</comment></comment></comment><comment><USER9> @Author : What you should do ?

Use Angular. Every single thing you mentioned there is covered. Except coffeescript, but thats unrelated anyway.

Whats covered ?

Async code : check. ( timeout flush )

Wrapper for XHR : check ($httpBackend ).

DOM abstraction : check ( No DOM Manipulation in controllers! )

fast feedback : check ( karma ) .

</comment><comment><USER10> Re: Tests for Design Feedback. I used to follow that approach, but I found that it locks you into the implementation and adds unnecessary drag when refactoring.

Now I like to think of tests as black box and white box. I prefer black box tests because it tells me if the system works from the api or interface, while giving me the freedom to refactor and reimplement without unnecessary drag.

Now for my Shameless plug. If your test suite has lots of edge cases, the test suite takes a long time to run because the same setup logic is being run many times.

I created jasmine-flow to reduce the number of times the setup logic is run by reorganizing the tests into linear flows. [https://github.com/btakita/jasmine- flow](https://github.com/btakita/jasmine-flow)

I sped up my test suite about 10x (~400 seconds to ~40 seconds) doing this.

I know, it's not 1 second, but since these are black box tests, I know if things work in reality. What is really important for development flow is running individual tests quickly (< 1 second).</comment>


Schizophrenia and genius – TempleOS and the strange, sad case of Terry a Davis - <AUTHOR> https://steemit.com/computers/@winstonalden/schizophrenia-and-genius-templeos-and-the-strange-sad-case-of-terry-a-davis <comment><USER2> > but the America of the early 21st century is not kind to the mentally ill.

This line really strikes me and I have shared my thoughts on this before. Mental illness like Depression has become much more accepted and view as a real thing in the US and to me because it is something that people can experience without having the disease. The combination of physical and mental symptoms of depression can all be experienced without having depression. It can be understood by many people. But there are many other mental illnesses that are have symptoms foreign to most people and I think it makes it harder to sympathize and even understand.

Personally, I was diagnosed with Schizoaffective Disorder when I was 17 (16 years ago) and had many hallucinations and delusions. It messed up my college plans as my family didn't think I was safe enough to live on my own (which was correct). A few years ago, I was diagnosed with OCD. Now, my OCD isn't like the kind you see in movies or TV. I don't obsessively wash my hands or have to count. Mine is much darker. I have homicidal thoughts as well as what pretty much amounts to being a stalker. Again, it is hard to express to people my thoughts. I grew up pretty much thinking that I was going to end up in jail as my thoughts would get the best of me and I would act on them. It took me several years before my wife found out about my thoughts and that was only because I accidentally left a blog open that I was writing. She didn't understand and she was scared for her own life. It made me feel even more like a monster.

As I'm writing this I realize I'm getting off topic from the article, in a sense, and I don't know what I'm trying to accomplish. Maybe this is just me needing a release. We have come a long way in the US with mental health over the past 50 years but we still have a long way to go.</comment>


The housing market faces its next crisis as May rent and mortgages come due - <AUTHOR> https://www.washingtonpost.com/business/2020/05/03/may-rent-mortgages-coronavirus/ <comment><USER2> I saw a proposal recently that suggested the government mandate that existing loans (mortgages and business loans primarily) add the deferred period to the back of the loan, interest free. So if the lockdown is 3 months long, then your 72 month loan becomes a 75 month loan with an internal interest free 3-month period. This feels like a reasonable compromise to just nullifying the debts altogether, considering what an accounting nightmare that would be.

<comment><USER3> I have been thinking about these issues since the beginning of the crisis, and the two big questions I have are:

1) What do you do about bonds? A very large proportion of all debt is packaged into bonds, and reducing their yield will have a substantial effect on many pensions

2) Who is going to pay the wages of the people paid to administer these loans? Are they going to accept a deferral of their wages?

I am not trying to dismiss your idea; I had many similar ones early on, but I couldn't figure out how to square the circle.

<comment><USER4> > 1) What do you do about bonds? A very large proportion of all debt is > packaged into bonds, and reducing their yield will have a substantial effect > on many pensions

US Treasury pays bondholders some, but not all, of the interest income due. Shared haircut between bondholders and the taxpayers. This is a catastrophic loss with a nation state providing what amounts to insurance, and incredibly cheaper not only economically, but from the struggle and hardship many would face from foreclosure and relocation.

> 2) Who is going to pay the wages of the people paid to administer these > loans? Are they going to accept a deferral of their wages?

PPP loans (forgiven when used for payroll) for mortgage servicers. Those folks are still going to be needed to account for bondholder payments, with the Treasury picking up the tab instead of homeowners.

<comment><USER3> A taxpayer bailout solves a bunch of problems, at the expense of non-mortgage holders (AKA renters). It seems unjust to take from renters and give to property-holders, given that the latter are generally more affluent, and knowingly took a risk (by taking out a loan).

<comment><USER4> > It seems unjust to take from renters and give to property-holders, given > that the latter are generally more affluent, and knowingly took a risk (by > taking out a loan).

Life isn't fair. Renters have landlords with mortgages also, and renters are just as challenged as homeowners currently (30+ million unemployed, 1/5th of the US working population). Broad policy decisions have some moral hazard to be deprioritized.

The goal isn't fairness, it is to return to economical equilibrium as rapidly as possible.

<comment><USER5> As a renter and voter, my preferred policy solution is to suspend rental evictions, let the foreclosures go forward as mortgages are a risky asset, then let the market sort it out at auction. That sounds like a more market- oriented solution to me.

<comment><USER4> Over 62.5 percent of American homeowners have a mortgage, worth collectively over $10 trillion dollars (total equity is ~$18 trillion). You are entitled to your opinion, but are in the minority.

<comment><USER6> The percentage of homeowners who have a mortgage says nothing about how many rent vs own. That said, the relevant number seems to actually be higher.

<comment><USER4> 64.2 percent of Americans are homeowners. Still a majority compared to renters.

<comment><USER6> > Still a majority compared to renters.

I'd noted it was higher so that would follow, yes. I left out the precise number because I saw some variation in the across sources and couldn't be bothered to dig into the details as it didn't make a difference anyway.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> As a millennial renter, part of me wants to see lower home prices, but that also means other people being underwater. It's a tough generational predicament we've placed ourselves in. We want to encourage homeownership, but millennials aren't buying. We want homeownership to be profitable, because for most middle class families, the home is the largest financial asset. It's impossible to make all of these promises to people. If a 2008 repeat occurs again, it will only further reduce personal home ownership and increase institutional ownership.

<comment><USER8> I really wish people would stop thinking of their primary home as an investment. It's not. It's a liability. It requires maintenance and upkeep and does not generate revenue.

Unfortunately, since -- as you point out -- a home is nearly always a family's largest expense and often also largest store of value, people distort what it means to them financially and expect their home to appreciate in value well above and beyond inflation.

When you take out a mortgage to buy a home, you shouldn't have any preconceived notions about whether or not you'll be "underwater" at some point in the future. And really, it does not matter one bit if you're underwater. Unless something has also happened to your income stream, you just keep paying it, as you should. The borrowed money doesn't somehow magically become less money just because conditions have changed and your home's market value has dropped. The downside is, of course, that you may not be able to sell the house and move away until you've paid off more of your mortgage. But that's a risk you take when you sign that paperwork up front.

The home-as-investment thing is fairly uncommon in the world and seems to mainly be a US thing. I wish it would die, as it should. It only serves to distort the market, and fuels ever-increasing home prices, which makes it continually harder for the average family to own their own home, further increasing institutional ownership.

<comment><USER7> Home prices as a multiple of median income have increased in many cities outside of the US: London, Paris, Berlin, Hong Kong, the financialization of housing is likely driving a house-as-investment ethos beyond US borders. Some nations, like Japan, are notable exceptions due to local preferences.

</comment></comment></comment><comment><USER9> This is why I don't expect a "V" shaped recovery. Consumer spending will be down because a lot of people will be spending their income on paying their past-due bills.

Credit reporting is going to hurt a lot of people too, and that will also decrease consumer spending because people will have less access to credit.

<comment><USER10> Also, many of the lost jobs are in consumption and service industries. I'm not going to get extra haircuts, eat extra meals, or drive extra miles.

So business owners and workers in those industries aren't going to catch up.

</comment></comment><comment><USER11> forbearance and tax relief will do wonders for those who own properties however this does nothing for renters or cover the other considerations, food and utilities.

the only solution is to replace lost income with a maximum cap of how much is restored. As in, take the reported income filings or individuals across a set period prior to the nationwide lockdown and use that to determine aid to go to those people. No wholesale just because you are breathing you get money. No bonus on top of it for children. Hence the number will likely need to be larger than $1200 for one month and taxes at all levels need to be forgiven for the air. I am betting on nearly $2000 per income earner up to their income or that cap.

however you will have to accept you will have people who will waste this money as well, you can easily find numerous cases where people treated the last stimulus as a bonus

</comment><comment><USER12> This is paywalled for me, an archive.is link: [https://archive.is/TSF1O](https://archive.is/TSF1O)

</comment><comment><USER13> Part of me has wondered... What if we just went through the motions of the economy? I.e., average everyone's spending over the last year and require everyone to make 1/12 those payments to their recipients per month. Obviously we wouldn't be realizing the benefit of the things we mock buy, but it seems to me like it would largely preserve the economy in the sense that no one would have to face a deficit? Anything still possible to deliver (i.e., food, rent, etc) would be delivered for the money and anything that couldn't would just not be.

Obviously there are many practical issues with this, namely that it would require way more and detailed data on purchases than anyone has and would be completely politically infeasible.

<comment><USER14> Different idea: just hibernate the economy. Completely. No money transfers. Nobody pays rents or food or bills; nobody gets paid either salary or pensions (but still has to show up for work if required/ possibile). This could help preventing businesses or private individuals or families going broke during the lockdown; when it's time, everything can be restarted at once. It might work (or have worked) for a short period of time, though I imagine it's practically inconceivable.

<comment><USER7> People need food to live. Are grocers expected to hand out food without payment? If everything is priced at $0, I might not make it to the grocery store fast enough before the crowd empties the place.

<comment><USER14> True. But you could for example say that every citizen has a right to $50 worth of food (at normal prices) per week, and has to pay any excess. Grocers might get partial refund from the government for the food already in stock; new orders going down the supply chain are not paid at all. (Btw, I know this is a crazy idea, but just for the sake of the argument).</comment></comment></comment></comment>


UK court ruling says email signature blocks can sign binding contracts - ga-vu https://www.theregister.co.uk/2019/09/30/email_signature_legally_binding_contract/ <comment><AUTHOR> This was essentially already established, I believe, in relation to contracts and signatures in general in electronic communications.</comment>


Parallel Distributed Processing Models of Memory - <AUTHOR> http://www.encyclopedia.com/psychology/encyclopedias-almanacs-transcripts-and-maps/parallel-distributed-processing-models-memory <comment><USER2> Source of the article, [https://stanford.edu/~jlmcc/papers/PublicationFiles/MISC_man...](https://stanford.edu/~jlmcc/papers/PublicationFiles/MISC_manuscripts_Dates_Unknown/McClellandXXParallelDistributedProceesingModelsofMemory.pdf)</comment>


Google Webfonts, the Spy Inside? - <AUTHOR> http://fontfeed.com/archives/google-webfonts-the-spy-inside/ <comment><USER2> This may be an unpopular sentiment, but here goes.

The hyperbole over this kind of reasoning threatens the very fabric of the Web. Snowden did the world a service in revealing all of the NSA hacking going on, but the paranoia that is resulting from this is breaking the original spirit of the Web.

It is, after all, a Web of links, and those links were intended to be not just between siloed content, but between different sites owned by different people. Links by their nature, permit tracking. All you need for for sites to pool their web logs and collude, you don't even necessarily need fancy JS tracking.

When Web 2.0 was ushered in, there was an early euphoria in the community, of everyone offering transparent data and APIs to their sites, and people being able to easily compose content and services between multiple actors to make new sites and services.

It is one of the things that makes the Web better than native -- the ability to compose parts of the Web. No need for stuff like OpenDoc, or other notions of document composition, all you need are URLs and semantic elements that import or interface with external resources.

In the pursuit of paranoia levels of "privacy", what will we lose? Will we balkanize everything into content silos?

I'm not against trying to make things more "private by design", e.g., proxying to scrub requestors before the CDN sees the hit, or replicating resources locally. But if we take this to the extreme, we end up making local copies of everything, and the Web loses some of the semantic information from it's graph that I think is valuable to retain.

<comment><USER3> A simple "noreferrer" (or referer if you like) tag on elements or in pages would solve a lot of this. 3rd parties would obviously still get the request, but they wouldn't know what page it comes from.

Interesting that "norel" got adopted so quickly for spam. So it shouldn't be hard to have a "noreferrer" tag added, right?

Yes, users can install addons to modify header behaviour, but site designers should be able to use third parties without disclosing things, too. Not just privacy, but security. Currently, apps need to implement a bouncer page to hide sensitive referrers.

<comment><USER4> _So it shouldn 't be hard to have a "noreferrer" tag added, right?_

It's so not hard that it's actually already a part of HTML5 and supported by several browsers :-) [http://www.w3.org/TR/html5/links.html#rel- noreferrer](http://www.w3.org/TR/html5/links.html#rel-noreferrer)

<comment><USER3> Seems like it isn't on link, image, or script elements though, which is the way most third party content gets loaded.

</comment></comment></comment></comment><comment><USER5> I'm not speaking in any official capacity, but to at least get the conversation started off with data, here's Google's public FAQ regarding the Fonts API privacy policy:

      https://developers.google.com/fonts/faq#Privacy

_What does using the Google Fonts API mean for the privacy of my users?_

The Google Fonts API is designed to limit the collection, storage, and use of end-user data to what is needed to serve fonts efficiently.

Use of Google Fonts is unauthenticated. No cookies are sent by website visitors to the Fonts API. Requests to the Google Fonts API are made to resource-specific domains, such as fonts.googleapis.com, googleusercontent.com, or gstatic.com, so that your requests for fonts are separate from and do not contain any credentials you send to google.com while using other Google services that are authenticated, such as Gmail.

In order to serve fonts as quickly and efficiently as possible with the fewest requests, we cache all requests made to our servers so that your browser only contacts us when it needs to.

Requests for CSS assets are cached for 1 day. This allows us to update a stylesheet to point to a new version of a font file when it's updated. This ensures that all visitors to websites using fonts hosted by the Google Fonts API will see the latest fonts within 24 hours of their release.

The font files themselves are cached for one year, which is long enough that the entire web gets substantially faster: When millions of websites all link to the same fonts, they are cached after visiting the first website and appear instantly on all other subsequently visited sites. We do sometimes update font files to reduce their file size, increase coverage of languages, and improve the quality of their design. The result is that website visitors send very few requests to Google: we only see 1 CSS request per font family, per day, per browser.

We do log records of the CSS and the font file requests, and access to this data is on a need-to-know basis and kept secure. We keep aggregated usage numbers to track how popular font families are, and we publish these aggregates in the Google Fonts Analytics site. From the Google web crawl, we detect which websites are using Google Fonts, and publish this in the Google Fonts BigQuery database. To learn more about the information Google collects and how it is used and secured, see Google's Privacy Policy.

For further technical discussion of how Google Fonts serves billions of fonts a day to make the web faster, see this earlier tech talk from the Google Developers YouTube channel.

<comment><USER6> This particular issue has come up in previous HN discussions, but I would draw people's attention to innocuous and quite reasonable-sounding phrases like "need-to-know basis." What does that really mean for a company like Google, whose core business model fundamentally depends on extensively data-mining user information? "Need-to-know" could mean almost anything, or whatever Google wants it to mean. This is a classic Google privacy strategy: controlling the debate by defining the terms.

Despite a reassuring policy, you, as the website visitor, don't get to decide these things and to the extent possible, the fact that this is even happening is abstracted away from most non-technical users.

Another example of Google's brilliance in 'controlling the debate by defining the terms': policies like this cleverly (but wrongly) lead the reader to assume that cookies are the only way Google tracks users or correlates their activities. What about TLS-based tracking mechanisms, for example?

But this is a problem that's bigger than Google. When information accumulates in distinct places, the value of exploiting that information always increases. Eavesdroppers naturally move to those places to exploit that information, sometimes with a legal backing (NSA/GCHQ) and sometimes without one (Aurora attacks, and other NSA/GCHQ activities).

Even if you interpret Google's pronouncements charitably, it would be a mistake to assume that using the Google Fonts API can't or won't harm user privacy. Google is a massive target for essentially all eavesdroppers, and the Aurora attacks (and other breaches with lower profiles) show that the accumulation of information--even under reasonable-sounding terms like Google's--can still end up in the wrong hands, and can be an inherently dangerous thing for user privacy.

<comment><USER7> (not talking for google) Two quick points:

\- The fonts have to be hosted somewhere. And the more common the hosting site is, the better the browser cache behavior is.

\- The cache behavior prevents requests from going out. If the font is cached, then there's no web request going back to google. And there's no web request on the wire for NSA/GCHQ/Verizon to sniff.

As for the terminology, I personally think that there should be some standards for defining the terminology and criteria, so that we can get human-readable privacy policies without getting uselessly vague, into a discussion of how some backend systems work, or into a giant mess of legalese.

<comment><USER6> It really depends on the relevant counterfactual; yours makes total sense from the vantage point of lots of developers, but I tend to prioritize privacy and autonomy. When I visit catphotos.wordpress.com, my intention is not to leak information to Google even though they have great fonts. My intention is just to visit the website.

So the counterfactual I would frame the discussion with would be something more like self-hosting fonts by default and prioritizing privacy over performance (different strokes for different folks, and I realize it can be a significant performance hit).

To respond to your "more common the hosting site is" comment, Wordpress is _also_ extremely common, and they probably could have devised alternative solutions by making different trade-offs.

Cache behavior resulting in fewer requests can be a double-edged sword, too: if you cache fonts with clients, you're probably _also_ caching a bunch of other things that may decrease your privacy in other ways. There are many layers of indirection, especially with NSA/GCHQ/Verizon.

I wouldn't argue that this and another services offered by Google don't add value for developers and even users (they absolutely do), but my argument is mainly that there are costs--maybe distant/abstract/indirect costs in terms of privacy/autonomy that are difficult to discuss in concrete terms, but costs worth considering nonetheless.

I wish WordPress had been more thoughtful about the trade-offs they made.

<comment><USER8> > I wish WordPress had been more thoughtful about the trade-offs they made

More accurately, you wish that WordPress had agreed with your priorities. They clearly did think about this and made a different decision and it's unfair to suggest otherwise.

</comment></comment></comment></comment></comment><comment><USER9> On the face of things, concern over this type of 'privacy violation' seems to be reasonable. However, coming from a page that is loading content from Fontfeed, Twitter, Gravatar, Google APIs, Fontshop and lo...Google Analytics, I think it's a bit of a silly argument.

If you want privacy, don't expect the sites you are hitting to take care of that for you. If you expect others to enforce security for you, well then, you have an entirely different problem.

<comment><USER10> This doesn't imply that, as a webmaster, you should be fine with asking browsers to load external resources from third parties with potential privacy implications, just because privacy-conscious users should have disabled it by themselves.

<comment><USER9> I'm not sure, as a webmaster, that I have any better control over my user's data than Google's font service does. If I think I do, I'm probably naive.

</comment></comment></comment><comment><USER8> A good way for Google to address this would be by enabling CORS and encouraging the use of crossorigin=anonymous to avoid credentials being sent for fonts:

<link href='[http://fonts.googleapis.com/css?family=Open+Sans'](http://fonts.googleapis.com/css?family=Open+Sans') rel='stylesheet' type='text/css' crossorigin='anonymous'>

Unfortunately, a quick test ([http://chris.improbable.org/experiments/browser/webfonts/goo...](http://chris.improbable.org/experiments/browser/webfonts/google- fonts-crossorigin.html)) shows that this can't be done currently because fonts.google.com doesn't have an Access-Control-Allow-Origin header:

[https://redbot.org/?uri=http%3A%2F%2Ffonts.googleapis.com%2F...](https://redbot.org/?uri=http%3A%2F%2Ffonts.googleapis.com%2Fcss%3Ffamily%3DDancing%2BScript)

(Oddly, the actual fonts are served with "Access-Control-Allow-Origin: *" so it works if you self-host the CSS, which would presumably be a bad idea: [https://redbot.org/?uri=http%3A%2F%2Ffonts.gstatic.com%2Fs%2...](https://redbot.org/?uri=http%3A%2F%2Ffonts.gstatic.com%2Fs%2Fdancingscript%2Fv6%2FDK0eTGXiZjN6yA8zAEyM2S5FJMZltoAAwO2fP7iHu2o.ttf))

This is the behaviour defined in the HTML5 spec:

[https://html.spec.whatwg.org/multipage/infrastructure.html#c...](https://html.spec.whatwg.org/multipage/infrastructure.html#cors- settings-attribute)

In some ways, this feels like an oversight in the spec because crossorigin=anonymous is actually better than the legacy behaviour but any use of the crossorigin attribute triggers mandatory full CORS checks.

<comment><USER11> Google has little to gain from these.

<comment><USER8> Google has an interesting position advocating for improved privacy and security. This would be a cheap way for them to back that up at relatively minimal expense.

</comment></comment></comment><comment><USER12> I use NoScript and Policeman on Firefox, with conservative settings (disallow all active content (scripts, fonts, WebGL), whitelist-only cross-site requests). I've also configured Firefox to block cookies by default; only permitted sites can store cookies for the session, and just a handful I allow permanent cookies.

Web pages load much quicker, Firefox uses less resources, my browsing is significantly more secure (see [1] for risk of loading arbitrary fonts), and I can browse the web without Google/Facebook/AdvertizingCorp (and thus the Five Eyes) building a profile of everything I do. It's a nice feeling.

This set up also blocks ads served from third parties, which I feel is an agreeable compromise on web advertising. If I send a request to your website, and you send me a document with embedded images stored on your website, I'll download them and view them alongside the page. However, if you try to tell me "go send 5 unsecure requests to each of these three companies you've never heard of, and execute their 20KB of code, to get flashing ads alongside this page" \- I'll ignore you.

Sites loading resources from external domains (usually Google) is nothing new. I've been browsing this way for two years now, and I've developed a healthy level of contempt for 95% of web developers. The vast majority of them just don't care for their users; campaigning to get the developers to change their habits is a broken model. Ultimately, you have to take control, and decide for yourself what you want to run on your computer.

I don't know why more people don't browse this way; some actually ridicule this approach ("get with the times"). It boggles the mind.

[1]: [https://hackademix.net/2010/03/24/why-noscript-blocks-web- fo...](https://hackademix.net/2010/03/24/why-noscript-blocks-web-fonts/)

<comment><USER3> The real quote there being:

" It really worries me that the FreeType font library is now being made to accept untrusted content from the web.

The library probably wasn't written under the assumption that it would be fed much more than local fonts from trusted vendors who are already installing arbitrary executable on a computer, and it's already had a handful of vulnerabilities found in it shortly after it first saw use in Firefox.

It is a very large library that actually includes a virtual machine that has been rewritten from pascal to single-threaded non-reentrant C to reentrant C... The code is extremely hairy and hard to review, especially for the VM.

"

FreeType's news page [http://www.freetype.org/index.html#news](http://www.freetype.org/index.html#news) \- has something very curious. Two fixes for the same CVE, but the second fix 9 months later. A look at the CVEs[1] for it is also interesting that they're all memory safety issues (at least, from a quick glance). So in 2014, it's still difficult to read fonts without exposing yourself to code execution vulnerabilities, eh? I'd imagine better languages would help here.

1: [http://web.nvd.nist.gov/view/vuln/search- results?adv_search=...](http://web.nvd.nist.gov/view/vuln/search- results?adv_search=true&cves=on&cpe_version=cpe:/a:freetype:freetype:2.0)

</comment></comment><comment><USER13> Not using external service for font anymore because it's blocking. That means your time to first render is directly impacted by the time your user download fonts from a third party.

And have you ever landed on a site fully rendered but can't see the text? High chances that it's a third party font that can't be downloaded for whatever reason.

</comment><comment><USER14> Another good reason to install Privoxy - [http://www.privoxy.org/](http://www.privoxy.org/)

Add the following to the config and you'll still be able to retrieve fonts and other shared stuff from Google's servers, but it'll block any tracking cookies and hide the referring site:

      { +crunch-incoming-cookies \
        +crunch-outgoing-cookies \
        +hide-referer(forge) }
      .googleapis.com
      apis.google.com

Unfortunately, it won't help against SSL sites.

<comment><USER15> _Unfortunately, it won 't help against SSL sites._

Proxomitron will, although its not open-source, its author has passed away, and it's only being maintained by the community. Among the things I use it to block are these "unexpected links to Google" and if it's something like jQuery or fonts I can have the proxy host it locally.

</comment></comment><comment><USER16> Aren't these web fonts just files they can include with their code? Why include anything from any 3rd party, it's a security and privacy issue.

<comment><USER17> using font files from a popular public cdn like google fonts is a good idea as they are generally highly available and are generally already cached on the user's machine from use on other sites.

<comment><USER16> Kbar, why do you need "highly available" fonts when you can bundle them in your web site? If the web site is up, fonts will work, if not fonts won't be needed anyway.

Regarding caching, anyone knows how browsers cache content? I.e. if I host my own fonts and someone visits me, then visits another web site with same fonts.. are they retrieved from the cache or downloaded yet again? I'm guessing they are downloaded again which is unfortunate..

<comment><USER7> AFAIK, the fonts are hosted as regular URLs with cache policies specified in HTTP headers. So, if you host your own fonts, and someone visits your site and someone else's site with the same fonts, they will download it twice (unless the other site's referring to your site in the URL). The browser doesn't know that they're the same font until after it downloads it (twice).

<comment><USER18> Fonts are a small subset of a site that makes a conscious decision to use a third-party font. There are many other resources being downloaded, which may or may not be duplicated. If the sites are revisited, they will be cached.

</comment></comment></comment></comment></comment><comment><USER19> For the end user 3rd party fonts can be blocked via Adblock Plus;

[https://secure.fanboy.co.nz/filters.html](https://secure.fanboy.co.nz/filters.html)

<comment><USER20> Or Ghostery, which only blocks trackers, but allows privacy-friendly ads.

<comment><USER19> "privacy-friendly ads", all ads need to track on some level, so it will only depend on which company you trust more.

</comment></comment></comment><comment><USER21> What the hell is wrong with the fonts my browser already has installed?

<comment><USER3> Going through exactly this when trying to optimize a site for a large company. Designers ended up with a little cursive font for headings. Getting approval from bigcorp takes forever. So many months in, that's the design.

There's no cursive-looking font that is commonly available on all machines. So we either have to use a font, or render images. Since it's used in more than a couple places, the font ends up taking less time.

Or I could try fighting the design, customer relationship, corporate branding, etc. teams to convince them the site's better off with just "Sans-Serif". In short: fonts aren't going anywhere.

Now, it would be nice if a dozen or two fonts of varying styles were included by default with browsers. But I imagine that'd just lead to designers raging about how <someone> is trying to limit creativity and enforce conformity.

FFS, many fonts don't even render properly on Firefox on Windows (like on medium.com) so I highly doubt usability is being considered as a main priority here.

</comment></comment><comment><USER22> Is this only a font problem? Many sites serve jQuery and other files from Googles CDN. Aren't these the same problem? Also there are other widely used CDNs that could affect your privacy .... will this not get very far, when you want to avoid any of these??

</comment><comment><USER6> This seems to be a growing problem, even among so-called 'privacy advocates.' The last time I checked, EFF's Privacy Badger extension was designed around having no qualms about making exactly these types of bad trade-offs on users' behalf.

The cost of your privacy--even in the eyes of the EFF--sometimes is worth little more than reliably serving a font or a copy of jQuery and claiming to respect 'Do Not Track'.

</comment><comment><USER23> I do find it odd that Wordpress would call these fonts from the authenticated section of the site. If it was just a bundled theme or plugin served publicly I don't really see the big deal, it is the __web __after all. But in my opinion authenticated sessions are authenticated for a reason, thus requesting assets from an un-authenticated resource does seem to be a concern. Just bundle the font!

</comment><comment><USER24> I still don't understand why don't the major browsers ship with at the very least a copy of jQuery installed locally, and then create a way to replace that URL for the locally installed version. No request made, faster access times, is there any downside?

<comment><USER25> If sites are reliably hitting a major CDN (like Google) for jQuery, then you get that advantage through caching anyway. The problem is that they don't, and if they're hosting their own jquery.js, there's no way to know before you download it that the script can safely be replaced with the known jQuery. I can imagine a scheme where the browser sends a hash of what it thinks the file is and the server only sends new content if it's different, but that would be a massive change, probably at the protocol level, to standardize, and doesn't do you any good if the bottleneck is a server that's slow to respond.

<comment><USER26> You've just reinvented HTTP Etags. :) It's a cookie-like resource caching mechanism where the server can return an arbitrary value (usually a hash or timestamp).

[https://en.wikipedia.org/wiki/HTTP_ETag](https://en.wikipedia.org/wiki/HTTP_ETag)

<comment><USER27> Well, no. There is no requirement in the standard for how Etags are implemented, so there is no way to use them outside of treating them as server-specific opaque tokens. They are useless for the parent's concept.

</comment></comment></comment></comment><comment><USER28> An even better reason to avoid using Google fonts is that they're frequently slow as molasses. Part of the issue is that fonts are frequently used badly and that browsers often don't handle them well, but it's still one of the more annoying things online.

</comment><comment><USER29> Can you not just put 127.0.0.1 fonts.googleapis.com in your hosts file?

</comment><comment><USER30> Thank you for making me aware of this insanity. I'll make sure to block those on my sites. The thoughtless denial of privacy is so weird, no one seems to mind letting third parties spy on their visitors. Yes, you, Google, jquery, cloudflare, typekit, gravatar, disqus and whatever your names might be.

<comment><USER9> The only person that really cares about your privacy is you. It's cognitive dissonance to believe otherwise.

<comment><USER31> And yet plenty of people with the knowledge and means to ensure their privacy online and elsewhere get spectacularly vocal about the privacy of those who have neither.

<comment><USER9> I think we _should_ get spectacularly vocal about protecting people-who- don't-know-better's privacy rights. We created this damn thing called the Internet, and sold it to them as this awesome tool. We should at least try to secure it better.

It is my belief that decentralizing services is one possible solution to this problem. At a minimum, having the user store their data at home on servers they plug-in and turn-on may be the solution. We're a ways out from that, but I'd much rather see people pushing the argument toward decentralization than faulting a website owner for using nice looking fonts for their gluten free pie crust recipe. Everyone knows what happens when hackers get access to your pie crust. They eat it.</comment></comment></comment></comment>


Ask HN: Why don't these applications have more competition? - <AUTHOR> 1. Alternatives to MS Sharepoint don't seem to be mature or give similar features. Specifically I need a document repository to see a history of documents and their changes. Of course multiple users must be able to edit and access and edit or checkout docs. It must also be internally hosted. Why hasn't Sharepoint been killed yet?<p>2. Non-Wordpress cooking blog templates. As a static blog enthusiast myself, I can't find any that have cooking blog templates. I can imagine some yaml headers for ingredients and recipe steps, then the rest of the page for extra fluff like photos. I want it to do all the hard work for me such as adding hrecipe tags, format the recipe to be print and mobile friendly, etc. I'm having to make a cooking blog from scratch which just seems crazy and exhausting. <comment><USER2> 1\. Support potentialities, presence, branding and readyness technical integrations (MS stacks, Active Directory), but a lot of competition is going on.

Apache Jackrabbit - [https://jackrabbit.apache.org/jcr/index.html](https://jackrabbit.apache.org/jcr/index.html)

[http://portals.apache.org/jetspeed-2/features.html](http://portals.apache.org/jetspeed-2/features.html)

[https://www.exoplatform.com/#platform](https://www.exoplatform.com/#platform)

[https://www.jalios.com/jcms/](https://www.jalios.com/jcms/)

[https://www.alfresco.com/](https://www.alfresco.com/)

[https://ofbiz.apache.org/](https://ofbiz.apache.org/)

[https://www.drupal.org/](https://www.drupal.org/)

2\. A higher level of abstraction seems beneficial.

</comment><comment><USER3> Sharepoint: Drupal does revisions on content and files just fine and supports super granular user permissions.

Cooking templates: Seems like you are overthinking this. Structure your recipes as yaml and then you can parse it however using handlebars or whatever template lang you choose. Not sure why you need such a specific template. Just choose a theme that looks nice and replace the header. Content is king anyway.</comment>