Spectre and the end of langsec - <AUTHOR> http://wingolog.org/archives/2018/01/11/spectre-and-the-end-of-langsec <comment><USER4> I'm starting to consider whether this reflects a larger failure in the industry/community: Traditionally, many of us (I'd say almost all) have been focused on security at the OS level and above. We've assumed that the processor and related hardware are safe and reliable.

However, below the OS level much new technology has been introduced that has greatly increased the attack surface, from processor performance enhancements such as branch prediction to subsystems such as Intel ME. I almost feel like Intel broke a social compact that their products would be predictable, safe commodities on which I can build my systems. But did those good old days ever really exist?. And of course, Intel naturally doesn't want their products to be commodities, which likely is why they introduced these new features.

Focusing on OS and application security may be living in a fantasy world, one I hesitate to give up because the reality is much more complex. What good are OpenBSD's or Chrome's security efforts, for example, if the processor on which they run is insecure and if there are insecure out-of-band management subsystems? Why does an attacker need to worry about the OS?

(Part of the answer is that securing the application and OS makes attacks more expensive; at least we can reduce drive-by JavaScript exploits. But now the OS and application are a smaller part of the security puzzle, and not at all sufficient.)

<comment><USER5> The issue of hardware security really has been ignored too long in favor of the quest for performance enhancement. Perhaps there is a chance now for markets to encourage production of simplified processors and instruction sets that are designed with the same philosophy as OpenBSD. I would imagine companies and governments around the globe should have developed a new interest in secure IT systems with news about major exploits turning up every few months now it seems.

</comment></comment><comment><USER6> Really not the end. The existence of issues that cannot be addressed via 'langsec' does not imply that we should give up on 'langsec'. There will be more security issues due to buffer overflows than there will be CPU bugs this year. More importantly, there will be orders of magnitudes more users with data compromised via buffer overflows, compared to CPU bugs.

<comment><USER7> The author does not seem to mean "the end of langsec" as in "everyone will give up on it", but rather the end of a period characterized, and not incorrectly, by the opinion that a safe programming language guarantees the absence of unintentional unsafe behaviour. In short, that things which, within this "langsec framework", one could prove to be impossible, turn out to be possible in practice; in the author's own words:

"The basis of language security is starting from a programming language with a well-defined, easy-to-understand semantics. From there you can prove (formally or informally) interesting security properties about particular programs. [..] But the Spectre and Meltdown attacks have seriously set back this endeavor. One manifestation of the Spectre vulnerability is that code running in a process can now read the entirety of its address space, bypassing invariants of the language in which it is written, even if it is written in a "safe" language. [...] Mathematically, in terms of the semantics of e.g. JavaScript, these attacks should not be possible. But practically, they work. "

This is not really news. The limits of formal methods were, in my opinion, well-understood, if often exaggerated by naysayers, brogrammers or simply programmers without much familiarity with them. Intuitively, it is not too difficult to grasp the idea that formal proofs are exactly as solid as the hardware which will run the program about which one is reasoning, and my impression is that it was well-grasped, if begrudgingly, by the community.

(This is akin to the well-known mantra that no end-to-end encryption scheme is invulnerable to someone looking over your shoulder and noting what keys you type; similarly, no software-only process isolation scheme is impervious to the hardware looking over its shoulder and "writing down" bytes someplace where everyone can access them)

<comment><USER8> > the end of a period characterized, and not incorrectly, by the opinion that > a safe programming language guarantees...

I don't think that there was ever such a period. Provable correctness always had the caveat of highly idealized assumptions, and we've known from the start that hardware vulnerabilities such as timing attacks, rowhammer, gamma rays, and power loss can undermine those assumptions.

</comment></comment></comment><comment><USER9> > Rich Hickey has this thing where he talks about "simple versus easy". Both > of them sound good but for him, only "simple" is good whereas "easy" is bad.

I don't think I've ever heard anyone mischaracterize his talk [1] this badly.

The claim is actually that simplicity is a fundamental property of software, whereas ease of use is often dominated by the familiarity a user has with a particular set of tools.

[1] [https://www.infoq.com/presentations/Simple-Made- Easy](https://www.infoq.com/presentations/Simple-Made-Easy)

<comment><USER10> Agreed, but I have see a lot of people come away from the talk with an unfortunate disdain for ease. Ironically, in disentangling "simple" and "easy", Rich created a lot of confusion about the value of ease.

</comment></comment><comment><USER11> My personal take is that perhaps chipmakers will start to see different market pressures. Performance is the big one, and it's been around since the first microprocessor. Power became increasingly more important, particularly in the past decade, from both ends of the market. (Both mobile devices and supercomputers are very power conscious.)

Security may become a new market pressure. You will likely sacrifice performance to get it, as it will mean simpler cores, maybe in-order, and probably without speculative execution. But, with simpler cores, we can probably further increase hardware parallelism, which will only partially mitigate the loss in single-threaded performance. Some chips may even be more radically security conscious, and guarantee no shared caches between processes. Such chipmakers would be able to say: we can't say for certain that these chips are fully secure, but because they are simpler with less attack vectors, we are far more confident they are. Security conscious chips may tend to be the ones that are internet facing (your mobile device, cloud data centers), and faster, less security conscious chips may only exist behind strict firewalls.

I bring this up in response to the submitted article because I find it unlikely that we will start to model processor insecurity at the language level. It ruptures too many levels of abstraction. I find it more likely that we will find ways to maintain those abstractions.

<comment><USER12> > Security may become a new market pressure. You will likely sacrifice > performance to get it, as it will mean simpler cores, maybe in-order, and > probably without speculative execution.

Maybe we go from having CPU + GPU to having CPU + GPU + FPU, where FPU = "Fast Processing Unit".

The CPU in the CPU/GPU/FPU model becomes simpler. Any time we have to choose between performance and security we choose security.

The FPU goes the other way. It is for things where speed is critical and you either don't care if others on the machine can see your data, or you are willing to jump through a few hoops in your code to protect your secrets.

For most of what most people do on their computers most of the time, performance is fine without speculative execution or branch prediction and probably even with caches that are completely flushed on every context switch. (It will probably be fine to leave branch prediction in but just reset the history on every context switch).

The FPU memory system could be designed so that there is a way to designate part of FPU memory as containing secrets. Data from that memory is automatically flushed from cache whenever there is a context switch.

<comment><USER13> I believe you can make a process noncacheable today, and maybe even disable branch prediction. This would totally shut down Spectre and Meltdown. You can disable SMT, and there's a whole host of other things you can do to isolate your "secure" process on an existing chip. Nobody has done these things because they like performance.

 _For most of what most people do on their computers most of the time, performance is fine without speculative execution or branch prediction_

I think you underestimate the importance of branch prediction.

</comment></comment></comment><comment><USER14> I think this is too dark a post, but it shows a useful shock: Computer Science likes to live in proximity to pure mathematics, but it lives between EE and mathematics. And neglecting the EE side is dangerous - which not only Spectre showed, but which should have been obvious at the latest when Rowhammer hit.

There's actual physics happening, and we need to be aware of it.

If you want to prove something about code, you probably have to prove microop semantics upward from verilog, otherwise you're proving on a possibly broken model of reality.

Second-order effects are complicated.

<comment><USER15> Rowhammer I can understand, but how do you come to that conclusion--"neglecting the EE side is dangerous"\--from analyzing Spectre? Does speculative execution rely somehow on physical effects? I can't find anything ( for example here: [https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...](https://en.wikipedia.org/wiki/Spectre_\(security_vulnerability\)) ) that suggests there is a physical component to this vulnerability.

<comment><USER16> I'd argue that using timing differences due to physical limitations of the hardware that to exfiltrate data based on whether or not it's cached is very definitely 'relying on physical effects'

<comment><USER15> > timing differences due to physical limitations of the hardware

I see; so you're talking about step two as described here, do I have that right?

[https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...](https://en.wikipedia.org/wiki/Spectre_\(security_vulnerability\)#Detailed_explanation)

This seems like a failure of algorithm design to me, in the sense of not starting with a better model that more accurately encodes the possibility of timing attacks. That being the case it appears to me to be a problem still firmly residing in the domain of computer science.

But, I'm a programmer, not a chip designer, and I have very little knowledge of this field, so I'm probably biased and not thinking about this correctly or with enough nuance.

<comment><USER16> Quoting the thread root:

> Computer Science likes to live in proximity to pure mathematics, but it > lives between EE and mathematics

which doesn't disagree with "firmly residing in the domain of computer science" \- it's merely a question of nobody having factored the right bit of EE into the right bit of math to get the right model.

</comment></comment></comment></comment></comment><comment><USER17> I don't see how this is fundamentally different than timing attacks and other side channel attacks that have been well known before, and to the best of my knowledge, simply hasn't been the focus of the "prove it correct" approach.

Whenever you want to prove something correct, you need to make assumptions about the execution model, and about what correctness means. Now "we" as an industry found a bug that makes the actual model differ from the assumed model, so we need to fix it.

The same is true when you can measure the power used by a microchip during some cryptographic operation, and infer the secret key from that -- even if the cryptographic operation has been proven correct, the definition of correctness likely didn't include this factor.

</comment><comment><USER18> While langsec can't easily mitigate spectre because the processor is trying to hide where the performance comes from, it's worth noting that several new languages are working on ways to write code where you can actually assert and have the compiler check that the timing of the code you write is bounded and uniform.

It's very easy, I think, to throw up our hands and say, "Well gosh all this language stuff is useless because timing attacks are so scary!" But in reality, they're pretty well studied and many of them are actually pretty simple to understand even if they can be hard to recognize.

Both hardware AND software sides of our industry need to start taking correctness, both at compile and runtime, seriously. The days where we can shrug and say, "But that's too slow, don't run code you don't trust" are dead. We killed them by ceding the idea of hardware ownership to big CSPs. The days where we can say, "This is too complicated to do!" or "This doesn't deliver customer value!" are also going away; the threat of combination attacks easily overshadows any individual attack, and small vulnerabilities tend to multiply the total surface area into truly cataclysmic proportions.

But also gone is the day when we can say things like, "Just use Haskell or OCaml!" We've seen now what these environments offer. It's a great start and it's paved the way for a lot of important understanding, but even that is insufficient. Our next generation of programming environments needs to require less abstract category theory, needs to deliver more performant code, and needs to PROVE properties of code to the limit of runtime resolution. The hardware and OS sides of the equation need to do the same thing. And we as engineers need to learn these tools and their techniques inside and out; and we shouldn't be allowed to sell our work to the general public if we don't.

<comment><USER19> > several new languages are working on ways to write code where you can > actually assert and have the compiler check that the timing of the code you > write is bounded and uniform.

I'm interested in how that would avoid the halting problem. Let's say I write code, compile it, and run some "timing verifier" on it. That verifier either runs my code and verifies that it's timing is correct _on that run_ , or inspects the machine code against a known specification of the hardware I'm running it on _right then_ and ensures all of the instructions obey my timing constraints. How would you check that the code's timing is bounded and uniform on subsequent executions? Or on other hardware? Or in the face of specifications that are incorrect regarding the timing characteristics of machine code instructions (CPU/assembly language specs are notoriously incomplete and errata-filled).

I suspect something fundamental would have to be changed about computer design (e.g. a "CPU, report thine own circuit design in a guaranteed-accurate way") to make something like this possible, but am not sure what that would be, or if it's feasible.

<comment><USER20> It avoids the halting problem the same way literally all sound static analysis does. With false positives. The java type checker will reject programs that will not have type errors at runtime. And a system that verifies timing assertions with SMT or whatever will reject some programs that will not fail the assertion.

The halting problem has never actually stopped static analysis tools. Static analysis tools that check timing assertions have been around for a very long time.

<comment><USER19> Sure, but this isn't a static analysis tool in the same way a type system is. This is an analysis tool which checks for mostly platform-unrelated, entirely runtime behavior which can vary based on a lot of external factors.

When you say "Static analysis tools that check timing assertions have been around for a very long time.", what are you referring to? I've used analyzers that check for potentially-inescapable loops, do assembly/machine code operation counts, and look for the presence of interruptions that are _known_ to take a potentially infinite/nondeterministic amount of time (waiting for I/O), or ones whose _lower_ bound in time is known (scheduler interactions like sleep). How would you analyze for instructions which have theoretically- constant times, but which in practice are vulnerable to "constant plus or minus"-type timing attacks like Spectre? How would that analysis yield results we don't already know, a la "in this section of code, you should obfuscate/prevent the gathering of timing data, and/or try to defeat speculative execution"?

<comment><USER18> There is no one here saying that there is a runtime that can protect against Spectre. Spectre is just one of extreme example of timing attacks which have been troubling our industry for the better part of a decade.

It's entirely possible to prove that some types of code do not significantly very they're running time based on the character of their input. A classic example of this is hashing algorithm whose execution time is only dependent on the length of the input.

I'm not sure if people recall password oracles but they're still valid attacks today. We can only eliminate these by starting at the bottom and working our way up.

If your response to Spectre is to give up on your computer security, I don't think I want you writing software for me. These are the challenges our industry has to face. Failure is not really an option.

</comment></comment></comment></comment></comment><comment><USER21> Everyone is assuming the author is giving up on Langsec. Read carefully, he called Spectre/Meltdown a setback. I think he's making a subtler point that the fundamentals of programming have become more of a pragmatic activity than a mathematical one, if you're being practical about your goals that is. I'm currently on the kubernetes multi-tenancy working group (which isn't really a working group yet) and its really funny to see how much effort is going into securing containers, but core bits like the CNI receive little attention. A wise security professional, ex hacker said that he actually liked over engineered security systems as a hacker, because it told him what not to focus on. Container security pretty good? Okay then figure out how to do what you want without breaking out of the container (definitely possible in the case of Spectre/Meltdown).

There is a fundamental cognitive bias in our field to solve the technically challenging problems without realizing that there are practical vulnerabilities that are far more dangerous, but a lot more boring to solve (the most common way orgs are exploited is through a combination of social attacks and something really trivial).

I think the author is frustrated because he feels the interesting work is unimportant in comparison to the practical.

That isn't to say that this work isn't helpful. I'm very glad to be working daily in a typesafe, memory safe language, but I have bigger fish to fry now as a security professional on the frontline.

</comment><comment><USER22> On the one hand, langsec specifically handles these problems. A program for searching through a file will produce the same results whether it runs in a tenth of a second or ten seconds, and as such doesn't need to - in langsec, shouldn't be _able_ to - access the time. That's what langsec is. It can even identify hazards like the SharedArrayBuffer high-res timers that compare the execution speed of different programs by communicating between processes; most programs shouldn't care which thread finished first, so that information shouldn't be available! And so we build formalisms for computing that don't make that information available to the program.

On the other hand, that's probably infeasible for the real world. Humans care about time too much for it to be declared off-limits to many programs. Similarly with things like communicating processes. These attacks are so fundamental that it'd be effectively impossible to build a program that didn't throw up an impenetrable wall of critical langsec violations.

So I'm not sure. The langsec framework _does_ offer a solution. It might just be that, in the same way that things like haskell offer their solutions, it's too difficult for the real world to apply it.

</comment><comment><USER23> There are CPUs that are immune to these attacks, including spectre.

The CERT recommendation was to throw away affected CPUs and use alternatives.

Now this isn't very realistic today when the in-order alternatives are slow and not comparable performance. But it does say that CERT is not giving up on langsec.

(Team Mill - we're immune too and will put out a light paper on how these attacks apply to in-order processors that support speculation and what we're doing to prevent them)

<comment><USER24> > Team Mill - we're immune too and will put out a light paper on how these > attacks apply to in-order processors that support speculation and what we're > doing to prevent them

Will this be sent to the mailing list when released?

<comment><USER23> Yes probably.

I've already written the paper and it's just got to survive a lot of peer review. It turns out that it would be real easy to envisage an in-order processor that has some mechanism for speculation that was actually vulnerable to spectre and variations of meltdown and the paper explores that - <USER2> hopefully it's an interesting paper even if the tl;dr is we claim to be immune.

<comment><USER25> I'm curious, because I think the Mill as described in the talks is vulnerable to a variant of Spectre. If you have a sequence of code like this:

        if (index < bounds) {
            index2 = array1[index];
            ... array2[index2];
        }

If the compiler speculates both array accesses above the bounds check, then the first one can still succeed (i.e. not produce a NaR) while accessing attacker-controlled memory for the value of index2.

You could obviously fix this by never generating code that does double speculation, but you could also do that by modifying a conventional OoO microarchitecture.

<comment><USER23> Spot on!

This variant of Spectre would be software bug not a hardware bug on the mill.

Our specialiser had to be fixed to _not_ produce code with this flaw.

And so we wrote a light paper on it, and perhaps a talk etc ;)

<comment><USER25> It seems that Mill's combination of a single address space and speculation- before-permissions-checks is still quite vulnerable to an ASLR leak. Have you made any changes to mitigate this, or do you just consider address space layout leaks acceptable behavior?

<comment><USER26> seriously? Mill is/will do speculation before perms? And here I thought turfs were the elegant answer to this nightmare.

<comment><USER25> See slide 72 of the metadata talk[1] and slide 51 of the IPC talk[2], which indicate that it does speculation before permissions checking.

Since turf permissions operate on the granularity of an arbitrary address range (rather than a page like traditional MMUs), the permissions cache (what the Mill calls a PLB) has a worse latency/power tradeoff than a traditional TLB. The Mill takes advantage of its single address space and reduces some of this hit by doing permissions checks in parallel with the access.

[1] [https://millcomputing.com/docs/metadata/](https://millcomputing.com/docs/metadata/) [2] [https://millcomputing.com/docs/inter-process- communication/](https://millcomputing.com/docs/inter-process-communication/)

<comment><USER23> Thank you for watching the talks! :D

Luckily its not quite as you interpreted:

The L1$D is accessed in parallel with the PLB. Both at top-level caches - <USER3> for data, one for protection.

If there is a PLB miss we have no cache-visible side-effects until the protection has been resolved.

The paper we're preparing will cover this in detail, because as you can see, the talks are a bit light on exactly what happens in what order when here.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> One of the big problems with Spectre and Meltdown is that they are due to behaviours and components of a processor that are not well documented. Caches, branch predictors, out of order execution and superscalar execution are all things that processor vendors refuse to disclose any information about because it is so commercially sensitive. Indeed CPUs are now primarily differentiated by these features. We are no longer getting processors with faster clocks or even smaller transistors so a lot of research has gone into making individual instructions run faster (or at least run faster most of the time).

Neither Intel, ARM or AMD have disclosed why their CPU design are, or are not vulnerable to Spectre and Meltdown. If the developers of compilers or even operating systems don't know exactly how the hardware works then it is pretty hard for them to know that they haven't written vulnerable code. By the same token, it is also hard for them to know if they have written performant code.

And we know even less about other types of processors that exist in almost every chip such as GPUs, digital signal processors, video processor units (VPUs) and other hardware accelerators. Those processors can almost certainly also leak data from other parts of the system, they have their own caches and sometimes branch predictors. Although it is hard to specify the code that runs on these devices it is almost certainly still possible to exploit bugs and timing attacks in them.

We are essentially getting security through the obscurity of the devices and security through obscurity is no good.

So should we have processor architectures which are completely open? In some ways that would destroy most vendor's business models. But having more openness could lead to more divergent processor architectures as vendors try to differentiate themselves and it should improve the security of our systems.

</comment><comment><USER28> Welcome to the cyberwar.

I think the basic problem with brakdown of static analysis tools like this one or optimisations like speculative execution is that they were built in a different time for significantly different requirements.

When the theories were developed, the main concern was to prove correctness and protect against accidents. Yes, the OS isolated processes from each other and protected memory boundaries - but this was added to keep a crashing process from corrupting other processes and bringing down the whole OS. It was _not_ developed to contain an actively malicious process.

At some point the paradigm changed and the idea spread that an OS shouldn't just protect against misbehaving _code_ but also against misbehaving _programmers_. That lead to the current practice of compartmentalizing a machine in different areas of trust and tightly restricting what a program _can_ do - and at the same time permitting increasing amounts of "untrusted" code to run because we trust the boundaries so much.

I think the general paradigm shift has some worrying sides, but more importantly, it was never explicitely discussed and it was never discussed if the current tools of software and hardware development can even support that new paradigm.

So yeah, in short, I think we are currently discovering that our houses are in fact not built to withstand a 20kton TNT blast set off at the front door. So far this hadn't been a problem as random violent explosions used to be a rare occurence. Somehow we got ourselves in a situation where they aren't rare anymore.

</comment><comment><USER29> Am I wrong in recalling that Itanium (IA-64) was an in-order architecture that relied on the compiler to explicate the potential for parallelism? Again, if I recall correctly, the struggle to construct compilers that could do this versus the apparent success (and lack of trade-offs) in letting in-processor circuitry to reshuffle instructions at run-time was one of the main reasons why _x_ 86's 64-bit extensions prevailed (the other being poor performance when running legacy _x_ 86 32-bit code).

Now it turns out that we really were benefitting from an advantage that had a hidden cost, not in terms of performance (though power might be a concern) but in terms of breaking the implicit model we have of how software executes, and that this disconnect in turn opens us to a host of "architectural" risks and metaphor breakages.

Maybe at this point we should consider reverting to the original plan and insist on compilers doing the legwork, so that approaches such as langsec have a hope of succeeding. Systems must be comprehensible (at least in principle) and reliably deterministic from the top all the way to the bottom.

<comment><USER30> Itianium relies on advance loads which is a form of speculation introduced by the compiler to perform competitively. It is not unlikely that this is as exploitable as spectre.

<comment><USER29> I respectfully disagree for two main reasons. Firstly, because the compiler is not transversal to all processes currently executing on the system at runtime, so it isn't a "unifying step" that conjoins otherwise independent processes and can allow them to interact. Secondly, if the compiler were found to be leaking state between processes, simply changing the compiler's logic would allow rectification of these issues (albeit at the expense of recompiling all software with the new compiler), with circuits etched onto a processor die one has no such opportunity. What could be (at least potentially) an open-source fix becomes the umpteenth binary blob from an opaque entity that tell us to "trust them because [they] know best".

<comment><USER30> Spectre is not (at least not directly), a cross address space vulnerability (although it can be exploited in some cases from other address spaces).

A JS JIT running on itanium that generates advanced loads before bounds checks will be vulnerable.

It is true that it can be fixed purely by software changes, by simply avoiding issuing advanced loads [1], but then again software changes can also plug the spectre v1 vulnerability on OoO architectures by adding artificial dependencies on load-load sequences (see the WebKit mitigation article that was discussed here a few days ago). Both software fixes have potentially significant performance issues (more so on in-order architectures).

So yeah, in-order CPUs are less microarchitecturally vulnerable [2] to spectre by default, but the compiler tricks required to make them competitive with OoO CPUs might reintroduce the issue.

[1] In principle compiler issued prefetches and load hoisting can be an issue on OoO CPUs as well, but as these are less important for performance compilers can be more conservative. On the other hand some VLIW architectures have special instructions and architectural support (like Itanium ALAT) to make this load hoisting easier.

[2] There are in-order ARM CPUs that have been reported to be affected though.

<comment><USER30> Thinking more about this, the vulnerability would be in any load issued speculatively which whose address depends on the result of a previous load. This can be detected at compile time and avoiding just this scenario it will not have such a performance effect as avoiding any speculative load.

</comment></comment></comment></comment></comment><comment><USER31> Here's a more optimistic take which is unavoidably a plug.

Urbit is maybe a sort of "extreme langsec." "Immune" is a dangerous word. Urbit is "premitigated" against Spectre for the following reasons, some cool and others stupid:

(1) The Nock VM has no O(n) data structures, ie, arrays. This was not anything to brag about till now.

(2) Urbit events are interpreted in their own process, which is one trust domain (one process, one "personal server").

(3) A personal server isn't a browser and doesn't habitually run code its owner doesn't trust.

(4) Urbit is purely functional, so you only know the time if someone passes you the time.

(5) Top-level event handlers are passed the time of the event. This is easy to fuzz.

(6) If you are running untrusted foreign code, it is probably just a function. Giving this function a measured time interval from top-level event times would be strange. And it would need another channel to exfiltrate the stolen data.

Never say never, but this combination of premitigations makes me worry about Spectre very little. Although, when we do have a less-trusted tier of applications (walk before run), ain't nobody is going to be telling them the time.

Besides the plug, the lesson there is that one of the reasons Spectre is a problem is that langsec is an imperfect bandaid.

Urbit is premitigated because it was designed as a functional system from the ground up. The JS environment is functional lite -- it allows typeless functional programming, but it also retains many mutable/imperative systems design tropes.

It's these tropes that have become clever attack vectors. If you don't want to get Spectred, build systems that are formal and functional all the way down.

<comment><USER32> >(5) Top-level event handlers are passed the time of the event. This is easy to fuzz.

Therein lies the rub -- if your program does not have access to precise timing information, it is by definition not operating at the full capability of the hardware which runs it. That's a hard sell to many domains.

Consider gaming. At 144Hz w/ 4K resolution you have 6ms to render a frame: that's about 1.3ns per pixel. If for a moment we imagine that it takes approximately 1 machine cycle per pixel to render a scene: that means you need to be operating at 1.3GHz just to meet the deadline for drawing to the frame buffer. -- That's before you consider memory & cache latency, or the fact that your multitasking OS is stealing resources for itself & other competing processes.

So no, one cannot just fuzz performance counters in the name of security. Any soft-realtime or hard-realtime domain is going to expect the machine to actually perform as advertised.

<comment><USER33> You are right: by definition real-time tasks will always be vulnerable.

With regard to Urbit, it is a non-issue because there are no use cases which would warrant access to soft or hard-realtime for a networked OS.

Such tasks will always happen on client-side, by virtue of network latency.

</comment></comment></comment><comment><USER19> > Spectre shows us that the building blocks provided to us by Intel, ARM, and > all the rest are no longer "small parts understood entirely"; that instead > now we have to do "basic science" on our CPUs and memory hierarchies to know > what they do.

I object to the term "no longer" in that sentence. There exist old CPUs that are not vulnerable to these attacks, but their existence doesn't mean that when those CPUs were in widespread use they were "understood entirely". I imagine that most programmers affected by the F00F vulnerability in Pentiums didn't fully understood what it was about the chip/microcode that caused the lockup, either.

The parts being assembled change over time, but I think you can always say "bah, {kids|engineers|scientists|etc} nowadays don't know how the things they're plugging together work" and be trivially "correct" without making any constructive point about how to go back to some nonexistent past in which things were understood. Even when computers ran on vacuum tubes and physical insects in machines as "bugs" ([apocryphal]([https://www.computerworld.com/article/2515435/app- developmen...](https://www.computerworld.com/article/2515435/app- development/moth-in-the-machine--debugging-the-origins-of--bug-.html)), I know), people didn't know the composition of the hardware. Would one of those programmers, on average, be more likely to fully understand, say the heat range required for successfully making circuits in a tube or the effects of anode corrosion on the lifespan of a tube, than a modern-day program would understand how CPU microcode works?

The amount of complexity per part might go up over time. But there's always a specialized threshold for "low level" understanding below which a) most people don't operate and b) dragons lurk.

</comment><comment><USER34> I find weird and worrying that you cannot analyze the safety of a program easily with some form of static analysis, or that there is no solution to do an automated security audit.

I have been bragging for a long time that there are no organized effort (state, government, scholars or otherwise) to teach basic software security in programming. There are no ISO standard for computer security, or at least there is nothing really relevant being taught. Security certifications don't really mean anything, or it seems nobody cares enough.

I guess governments will have to get preoccupied with those things, because you can clearly see that for now, it's an arms race kind of strategy, as long as the NSA has the upper hand, things are okay, but if it becomes a bigger national security concern, things might change. I guess you can smell that the russians are getting good enough and that it's time to make internet security a more prevalent matter for developers.

<comment><USER29> How can you hope to statically analyse something that executes non- deterministically and whose state depends on the goings-on of all the processes simultaneously hosted on that system? The whole point the author is making is that there is a step at the bottom of all formal reasoning hierarchies that doesn't behave deterministically and thus undermines formal reasoning about everything built above it. It's just that we had never recognised it as existing because we conveniently abstracted away this reordering of instructions and thus had a model of the runtime environment that doesn't match with reality.

</comment></comment><comment><USER35> > _Mathematically, in terms of the semantics of e.g. JavaScript, these attacks > should not be possible. But practically, they work._

Obviously this is badly stated.

It's not correct to say "mathematically they should be possible given the semantics of Javascript" and then say that "practically they work" as if implying that the mathematics somehow broke down.

It's not the mathematics that failed you, but the assumptions (axioms) you've used. Mathematically they are absolutely possible -- when you correctly account for the real processor behavior. And if you had mathematically modeled the whole "JS semantics + CPU behavior" accounting for Meltdown, mathematics would have shown that it's not safe.

</comment><comment><USER36> Spectre has nothing to do with program correctness or safety. It has everything to do with _hardware 's_ correctness and safety.

That is, the basic premise of hardware process isolation is that a process cannot have any knowledge of what another process is doing, or whether it even exists, unless it is explicitly permitted (e.g. the OS offers an API to look at processes).

This basic premise is now broken: enough information leaks via timing as to allow to read arbitrary memory regions. It's like you built a house laying bricks in a formally correct way, but the walls proved to be permeable because the bricks themselves have a flaw.

Since this flaw is not fundamental, that is, not even every currently existing processor exhibits it, it appears to be reasonable to replace the flawed design of the bricks, and not to re-engineer house construction.

There is a nice quote in the article, about doing basic science to find out how software (and hardware) _actually_ works, since specs are badly incomplete. It can be matched with another, earlier famous quote: "Beware of this code; I only proved it correct, I did not test it." Black-box testing of information systems is not going anywhere, formal methods or not; at the very least, we need evidence that formal methods were not visibly mis-applied, and also evidence that other basic premises, like those of hardware, still hold. Because sometimes they don't.

<comment><USER37> > Spectre has nothing to do with program correctness or safety. It has > everything to do with hardware's correctness and safety.

Yes, but safety is safety. The point of the article is that the assumption on the part of language nerds for the past few decades -- that correct choice of processes and implementation patterns as expressed by whatever favorite runtime the author wants can protect us from security bugs -- turns out to be _FALSE_.

Rust and Haskell programs are subject to Spectre attacks just as badly as K&R C ones from 1983. All that pontification didn't actually work!

The point is that it puts a limit on pedantry about "correctness". That's all based on an idea about a "computer" being an abstracted device, when it turns out the real-world machines are in fact leaky abstractions. The lesson to my ears isn't that you shouldn't use Rust or whatever, but that some humility about the boundaries of "correctness" would probably be a good idea for many of the pontificators.

<comment><USER38> _> All that pontification didn't actually work!_

This is a bit silly. Security is a chain that is only as strong as its weakest link. For decades we believed that C was the weakest link, and now, with Spectre, we have discovered (drumroll, please!): nah, C is still the weakest link. For all the amazingly scary things that Spectre brings to the table, it's still less scary than Heartbleed and Cloudbleed were.

Don't get me wrong, hardware still sucks (and with Intel and AMD's growing body of management engine incompetence they may yet overtake C as the weakest link in the chain) but we will learn from this and get better. In the meantime, we need to be pushing forward on all fronts: hardware security, language security, kernel security, application security, network security... nobody gets to stand still.

<comment><USER39> Long before Heartbleed or Cloudbleed researchers (and presumably attackers) were using remote timing attacks to extract secret keys:

      https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

And most big data breaches where information assets are actually stolen involve services written using "safe" languages, like Java or SQL.

And even if C is the weakest link, all that means is that you're totally screwed. No amount of Rust will save you when the Linux kernel, your relational database, and every router between you and the attacker are written using C or assembly.

At the end of the day, if you want strong security assurances you need to prove the correctness of all the semantics (of which memory bounds constraining is but one small aspect) of every piece of software in your stack, or at the very least all the most critical pieces. And the best tooling for that is for Ada and C.

</comment></comment></comment></comment><comment><USER40> The opening line that "The work of engineers used to be about taking small parts that they understood entirely and using simple techniques to compose them into larger things that do what they want" is not correct. Emergent behaviour has always been an issue for complex system. Just look at the story behind the Tacoma Narrows Bridge.

Computing is extremely complex, so the issue is probably more acute, but it is not unique.

<comment><USER41> I agree with you. Engineers of physical things don't fully understand what steel is made of (since we don't fully understand the lowest underpinnings of matter or all of its properties).

</comment></comment><comment><USER42> OK so do we finally get proper lisp machines now?

<comment><USER43> Lisp machines (at least, Symbolics Lisp Machines which I know well) didn't suffer from these flaws. They were largely designed to be single-user machines and there was literally almost no isolation between anything!

<comment><USER44> But weren't Symbolics Lisp Machines from an era where _nothing_ suffered from these flaws, because nothing did speculative execution?

<comment><USER43> As far as I know, this is true for the Symbolics Ivory CPUs, yes. That said, these flaws would be irrelevant, if so, because the system built upon the hardware did not enforce modern process isolation paradigms.

</comment></comment></comment></comment><comment><USER45> Security by proof, model checking, semantics is still a good, effective tool!

Leveraging the type system is a good communication channel for programmers maintaining the system.

Proofs and models of the protocols are still important.

But yes... we still need to fix CPUs. And the class of errors (those of omission) are still worth removing from our code regardless of spectre or meltdown.

</comment><comment><USER46> Security is an emergent property of a system consisting of users, software and hardware. Thus, a programmer cannot prove security of a system but merely assert its certain behaviour. Langsec does just that. No, it can never be used to build secure systems. Yes, it can be used to solve practical problems making things more secure.

</comment><comment><USER47> The author of this post isn't properly characterizing langsec:

 _The basis of language security is starting from a programming language with a well-defined, easy-to-understand semantics. ... This approach is taken, for example, by Google 's Caja compiler to isolate components from each other, even when they run in the context of the same web page._

From what I can tell, he's talking about the broader area of "programming languages and security". That is not the same thing as [http://langsec.org/](http://langsec.org/), which is essentially about using grammars to recognize network PROTOCOL formats.

As far as I remember, one motivating vulnerability is that there were two different parsers for SSL certificates, which allowed attackers to trick browsers into accepting invalid certificates. That doesn't have anything to do with programming languages per se; you can write this vulnerability in any language. It's analogous to the fact that using a safe language doesn't prevent you from SQL injection.

Some examples of what they are trying to address:

[http://langsec.org/papers/langsec-cwes- secdev2016.pdf](http://langsec.org/papers/langsec-cwes-secdev2016.pdf)

I wrote a critique of langsec a few months ago here:

[https://lobste.rs/s/uyjzjc/science_insecurity_meredith_l_pat...](https://lobste.rs/s/uyjzjc/science_insecurity_meredith_l_patterson#c_pzjzxh)

tl;dr I think they are using the wrong formalisms.

I found it odd that the author was assuming that langsec is a widely used thing when I think it is nascent research.

Even Google Caja, a totally different project outside of langsec, is not widely deployed, although I very much like its ideas.

<comment><USER48> Just FTR, your critique is answered by Stefan Lucks, Norina Grosch, and Joshua Koenig's paper[0] from last year's langsec workshop at IEEE Security and Privacy. They define a formalism, calc-regular languages, to handle length- prefixed strings.

[0] [http://spw17.langsec.org/papers.html#calc- regular](http://spw17.langsec.org/papers.html#calc-regular)

<comment><USER47> Thanks, this looks promising! I'll take a look.

</comment></comment></comment><comment><USER49> Hi Andy, thanks for writing this.

I don't think we are fundamentally hopeless for "langsec", although history will definitely be divided into two Epochs: a time before Spectre and a time after.

Language runtimes and operating systems just got some really great new research problems, and a lots of interesting ideas are afoot (many in V8 land).

<comment><USER20> There is no way that this is true. The program analysis community has known for decades that systems were only ever sound w.r.t. some assumptions. See Andrew Appel's paper on breaking java safety with mcdonalds heat lamps from like a decade ago for a fun example.

Basically every static analysis person I've talked to about this agrees that it is a really really cool attack but that it doesn't represent fundamental new information for the field.

</comment></comment><comment><USER50> I think there is a deeper truth here - understanding of what the hardware is doing has always been essential for writing correct, secure, performant programs - and it is the (IMHO, mistaken) ideology that this is not the case that took the biggest hit from Spectre/Meltdown/et al.

</comment><comment><USER38> _> One manifestation of the Spectre vulnerability is that code running in a process can now read the entirety of its address space, bypassing invariants of the language in which it is written, even if it is written in a "safe" language. This is currently being used by JavaScript programs to exfiltrate passwords from a browser's password manager, or bitcoin wallets._

Isn't this incorrect? I thought it was Meltdown, not Spectre, that was being used to read the browser's password manager from JavaScript, and that Spectre- via-Javascript was limited to reading data within the same JS VM process (so e.g. you could prevent Spectre from reading cookies by making them http-only). This matters because meltdown is much easier to patch than Spectre.

</comment><comment><USER51> This is like saying a compiler bug in a safe language ends langsec. Which is obviously absurd. It means the implementation had a flaw, but that doesn't make the whole thing worthless. And when the flaw is fixed the same guarantees are restored.

<comment><USER52> The problem is that what you call guarantees weren't guarantees to begin with, and we can't be sure they are now.

<comment><USER51> That's true about any engineering artifact though. If your steel rebar isn't built to whatever standard you require your concrete skyscraper isn't going to be structurally sound. To build on top of the layers below you, you have to trust that they work, and when problems occur you fix the problems as they come up (or ideally prevent them ahead of time).

</comment></comment></comment><comment><USER53> I am not seeing the connection to LANGSEC. The Spectre and Meltdown attacks turn the processor into a confused deputy, that is all. If anything, this is predicted by LANGSEC. The beef is not even with hardware verification, as some have suggested, because the specification never calls for such security guarantees. The specification is architectural because we want different processors to implement the same architecture, such that they are compatible. The only reason transient instruction sequences have security violating side effects is microarchitectural leaks.

</comment><comment><USER54> I think concluding the "end of langsec" goes too far. We'll continue to need both langsec, plus much more thorough hardware verification to re-establish basic isolation assumptions lost with Spectre/Meltdown (or push for detailed HW specs to begin with, to be able to assert these assumptions on our own).

OTOH, as if it wasn't obvious enough already, I'm seeing a serious issue with the concept of executing arbitrary code from untrusted network locations, such as with JavaScript on the Web.

</comment><comment><USER55> The failure lies in forgetting that computers are not deterministic machines, they are probabilistically deterministic machines instead.

They are physical constructs, not mathematical ones, and as such, verification is inescapable if you want some level of assurance. You need tolerances and experimentation after construction, even if you proved your thing correct.

In the words of Knuth: "Beware of bugs in the above code; I have only proved it correct, not tried it."

</comment><comment><USER56> The major chip manufacturers need to have two kinds of cores/caches. One that has full security guarantees, the other that is optimized for energy efficiency/performance and has zero interprocess security. This isn't a one size fits all problem.

<comment><USER57> I see some people assume that a possibility of a single chip that can do both is not option. It is. It's only x86 that has to do everything in hardware and hide everything from the user for backwards compatibility.

Imagine instructing a compiler for an architecture that does everything in software, like Mill, to make every operation constant time or to speculate aggressively and unsafely depending on what the program needs.

</comment></comment><comment><USER58> Even on the Arduino I don't think I could claim that I knew 100% what was going on, let alone go/python/JS -> kernel -> docker/VM -> -> kernel -> processor

</comment><comment><USER59> meh.

reasoning always loses out to empirical techniques anyway.

</comment><comment><USER60> Buy a new cpu that is fixed and problem gone maybe we shouldn't change the world maybe intel should fix there own problem? If a car has a serious fault that makes it dangerous it's recalled it's time for intel to do the same.</comment>


Chrome phasing out support for User-Agent - <AUTHOR> https://www.infoq.com/news/2020/03/chrome-phasing-user-agent/ <comment><USER2> The weird thing about this is that the only company I've seen doing problematic user-agent handling in recent years is Google themselves. They have released several products as Chrome-only, which then turned out to work fine in every other browser if they just pretended to be Chrome through the user agent. Same with their search pages, which on mobile were very bad in every non-Chrome browser purely based on user agent sniffing.

<comment><USER3> Every single Google product is slower on Firefox and it's hard to not call this malice and artificial. Many people check out Gmail and GMaps on Firefox and go back to Chrome because of their clunkiness on Firefox.

<comment><USER4> > malice and artificial

are you actually asserting that Google is purposefully adding code/"tweaking" their web apps to run slowly on browsers other than Chrome?

do you have any evidence at all for this other than anecdotes about people experiencing Google web app clunkiness on Firefox?

<comment><USER5> It could also be a passive, malicious de-prioritization of bugfixes for Firefox that would cause the same effect. It seems like this would be a more likely scenario.

<comment><USER6> I would believe that if changing the user agent or toggling some flags didn't fix it.

</comment></comment></comment></comment></comment><comment><USER7> > _[https://github.com/WICG/ua-client-hints](https://github.com/WICG/ua- > client-hints) _

I don't really understand how this will result in any real difference in privacy or homogeneity of the web. Realistically every browser that implements this is gonna offer up all the info the server asks for because asking the user each time is terrible UX.

Additionally this will allow google to further segment out any browser that doesn't implement this because they'll ask for it, get `null` back and respond with sorry we don't support your browser, only now you can't just change your UAS and keep going, now you actually need to change your browser.

And if other browsers do decide to implement it, they'll just lie and claim to be chrome to make sure sites give the best exp... so we're back to where we started.

<comment><USER8> > I don't really understand how this will result in any real difference in > privacy or homogeneity of the web.

It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies.

In any case I'm not sure privacy is the ultimate goal here: it's intended to replace the awful user agent sniffing people currently have to do with a sensible system where you query for what you actually want, rather than infer it from what's available.

<comment><USER9> Switching it from passive to active means you can count it towards [https://github.com/bslassey/privacy- budget](https://github.com/bslassey/privacy-budget) . Yes, sites can ask for all sorts of things, but if they ask for enough that they could plausibly be fingerprinting you then they start seeing their requests denied.

(Disclosure: I work at Google, speaking only for myself)

<comment><USER7> Is the "privacy budget" an actual feature of chrome or just an idea? I've never heard of it until now.

<comment><USER9> It's a proposal for how to prevent fingerprinting: [https://blog.chromium.org/2019/08/potential-uses-for- privacy...](https://blog.chromium.org/2019/08/potential-uses-for-privacy- sandbox.html)

<comment><USER10> It prevents others fingerprinting, not Google though. Isn't there that x-Client-Data header than chrome only sends to Google domains?

<comment><USER9> The X-Client-Data header is documented in [https://www.google.com/chrome/privacy/whitepaper.html#variat...](https://www.google.com/chrome/privacy/whitepaper.html#variations) and Chrome uses it to run experiments to make the browser better. It's not used for fingerprinting.

(Still speaking only for myself)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> Good. User-agent strings are a mess. Here is an example of a user-agent string. Can you tell what browser this is?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13

How did they get so confusing? See: _History of the browser user-agent string_ [https://webaim.org/blog/user-agent-string- history/](https://webaim.org/blog/user-agent-string-history/)

Also, last year, Vivaldi switched to using a user-agent string identical to Chrome's because websites refused to work for Vivaldi, but worked fine with a spoofed user-agent string. [https://vivaldi.com/blog/user-agent- changes/](https://vivaldi.com/blog/user-agent-changes/)

<comment><USER12> If companies like Google wouldn't abuse the user agent string to block functionality, serve ads, force their users to specific browser then companies like Google wouldn't have to use fake UA strings and then maybe companies like Google wouldn't have to drop their support.

</comment></comment><comment><USER13> This is a good idea, and is something I've thought of for a while; the user agent header was a mistake from both a privacy and a UX perspective.

Ideally, web browsers should attempt to treat the content the same no matter what device you are on. There shouldn't be an iOS-web, and a Chrome-web, and a Firefox-web, and an Edge-web; there should just be the web. In which case, a user-agent string that contains the browser and even the OS only encourages differences between browsers. Adding differences to your browser engine shouldn't be considered safe.

Beyond that, the user agent is often a lie to trick servers into not discriminating against certain browsers or OSes. Enough variability is added to the user-agent string that a server can't reliably discriminate, but it still remains useful for some purposes in JavaScript and as a fingerprint for tracking.

Which brings me to privacy. It's not as if there aren't other ways to try and fingerprint a browser, but the user agent is a big mistake for privacy. It'd be one thing if the user-agent just said "Safari" or "Firefox", but there's a lot more information in it beyond that.

If the web should be the same web everywhere, then the privacy trade-off doesn't make much sense.

<comment><USER14> I agree, but this also is incredibly dependent on the major players (e.g. Google) not going off on their own making changes without agreement from other browsers...

There are still issues today where chrome, edge, and Firefox render slightly differently. I certainly agree user agent isn't terribly necessary, but it's literally the only hook to identify when css or JavaScript needs to change... Or to support people on older browsers (e.g. Firefox ESR). How can I know when I can update my website to newer language versions without metrics _confirming_ my users support the new ES version?

I would argue simplifying the UA, product + major revision, maybe, or information relevant to rendering and JavaScript only

<comment><USER15> Thinking cynically, it could be a power-move by Google to strengthen their hold on the ecosystem.

Right now when they go out and make their own API changes without consensus (which already happens), it's possible to distinguish the "for Chrome" case and still support the standard. But if there were no User-Agent, and Google wanted to strongarm the whole group into something, and 90% of browsers are Chromium-based, devs will likely just support the Chromium version and everyone else will have no choice but to fall in line.

<comment><USER16> You mean, like SPDY/HTTP2 ?

<comment><USER17> As far as I can tell, HTTP/2 is such a major improvement that no strong-arming is necessary. Speaking as a consumer of the web, as an individual who runs their own website, and at a developer working at a company with a major web presence.

The web suffers a ton from the "red queen" rule in so many different ways anyway—you have to do a lot of work just to stay in the same place.

<comment><USER16> But, is it really such an improvement ? Or is it just an improvement for Cloud provider that keep pushing the Kool-Aid ?

I still see a lot of contradicting benchmark and, apart from some Google Apps, personnally, I have not seen a lot of sites actually really leveraging HTTP2 (including push).

But maybe you did put and leverage HTTP2 on your own website ? At your company ? Did you use push ? Do you use it with CDN ?

<comment><USER17> > But, is it really such an improvement?

Yes, unequivocally. It's amazing, even without push. The websites that use it are faster, and the development process for making apps or sites that load quickly is much more sane. You don't have to resort to the kind of weird trickery that pervades HTTP/1 apps.

> Or is it just an improvement for Cloud provider that keep pushing the Kool- > Aid ?

I don't see how that makes any sense at all. Could you explain that?

> But maybe you did put and leverage HTTP2 on your own website ? At your > company ? Did you use push ? Do you use it with CDN ?

From my parent comment,

> Speaking as a consumer of the web, as an individual who runs their own > website, and at a developer working at a company with a major web presence.

My personal web site uses HTTP/2\. It serves a combination of static pages and web apps. No push. HTTP/2 was almost zero effort to set up, and instantly improved performance. With HTTP/2, I've changed the way I develop web apps, for the better.

My employer's website uses every technique under the sun, including push and CDNs.

<comment><USER9> _> My employer's website uses every technique under the sun, including push and CDNs._

Are you actually seeing good results from push? I have seen many projects try to use it, but am not aware of _any_ that have ended up keeping it.

(Disclosure: I work at Google)

<comment><USER18> For comcenter.com I push CSS, except if the referrer is same origin.

I _think_ it's working pretty well as far as I can tell.

<comment><USER9> If you were up for running an A/B test (diverted per-user, since cache state is sticky) and writing up the results publicly I'd love to see it!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> At my employer we are using UserAgent to detect the browser so that we can drive SameSite cookie policy for our various sites (e.g. IE11 and Edge, which we still support, doesn't support SameSite: None).

There are a variety of scenarios where this comes up (e.g. we ship a site that is rendered, by another vendor, within an iframe; so we have to set SameSite: None on our application's session cookie so that it's valid within the iframe, thus allowing AJAX calls originating from within the iframe to work based on our current auth scheme.. BUT only within Chrome 70+, Firefox but NOT IE, Safari, etc).

Just providing this as an example of backend applications needing to deal with browser-specific behavior, since most of the examples cited in other comments are about rendering/css/javascript features on the client and how UserAgent drives that.

<comment><USER20> The proposed User Agent Client Hints API would replace this: [https://wicg.github.io/ua-client-hints/](https://wicg.github.io/ua-client- hints/)

<comment><USER21> The User Agent Client Hints API looks like a very early draft. I could not see any proposed timeline for implementation or estimate of when this might become a supported standard.

I would not personally rely on this as a substitute or replacement for User Agent by September (Google Chrome 85).

</comment></comment></comment><comment><USER22> These days, it feels like the sole use of User-Agent is as a weak defence against web scraping. I've written a couple of scrapers (legitimate ones, for site owners that requested machine-readable versions of their own data!) where the site would reject me if I did a plain `curl`, but as soon as I hit it with -H "User-Agent: [my chrome browser's UA string]", it'd work fine. Kind of silly, when it's such a small deterrent to actually-malicious actors.

(Also kind of silly in that even real browser-fingerprinting setups can be defeated by a sufficiently-motivated attacker using e.g. [https://www.npmjs.com/package/puppeteer-extra-plugin- stealth](https://www.npmjs.com/package/puppeteer-extra-plugin-stealth), but I guess sometimes a corporate mandate to block scraping comes down, and you just can't convince them that it's untenable.)

<comment><USER23> Preventing scraping is an entirely futile effort. I've lost count of the number of times I've had to tell a project manager that if a user can see it in their browser, there is a way to scrape it.

Best I've ever been able to do is implement server-side throttling to force the scrapers to slow down. But I manage some public web applications with data that is very valuable to certain other players in the industry, so they _will_ invest the time and effort to bypass any measures I throw at them.

<comment><USER24> As a person who scrapes sites (ethically), I think it's impossible or pretty damn near impossible to prevent a motivated actor from scraping your website. However, I've avoided scraping websites because their anti scraping measures made it not worth the effort of figuring out their site. I think it's still worth for do minimal things like minify/obfuscate your client side JS and use some type of one time use request token to restrict replay-ability. The difference between knowing that I can figure it in 30 minutes vs 4 hours vs a few days is going to filter out a lot of people.

Of course, sometimes obfuscating how your website works can make it needlessly more complicated, so it's a trade off.

</comment></comment></comment><comment><USER25> Meanwhile, you can still use youtube.com/tv to control playback on your PC from your phone—but only if you spoof your User-Agent to that of the Nintendo Switch [1]. Sounds like they are more interested in phasing out user control than ignoring the header entirely.

[1] [https://support.google.com/youtube/thread/16442768?hl=en&msg...](https://support.google.com/youtube/thread/16442768?hl=en&msgid=16717689)

<comment><USER26> Oh wow. I used that in the past and it worked great. I didn't realize Google broke it only to force us to use their app.

What a bunch of turds.

Thank you for the Nintendo Switch pro-tip.

<comment><USER27> Yes. I firmly believe this is an attack on user control.

For example, I believe they REALLY want us to use the youtube app:

\- Viewing youtube.com on a new iPad pro, Goolag lies and says "your browser doesn't support 1080p."

\- Ok, change to desktop version in app. Goolag once again lies and says "your browser doesn't support full screen." They also lie and say they've redirected you to the "desktop version", and nag you with a persistent banner that you should return to the safety of the mobile website.

\- Ok, change to "request desktop version" via user agent. Full functionality. Full screen is DEFINITELY possible with a javascript bookmark. 1080p+ is DEFINITELY possible. Ads blocked in browser.

If I were to use the app, they would have FULL CONTROL.

<comment><USER28> Are you deliberately misspelling Google as Goolag to make it sound like gulag?

</comment></comment></comment></comment><comment><USER29> This feels very ivory tower. It reminds me of the "You should never need to check user agent in JavaScript because you should just feature detect!!". Well in the real world that doesn't work every time.

The same is true for server side applications of user-agent. There are plenty of non-privacy-invading reasons to need an accurate picture of what user agent is visiting.

And a lot of those applications that need it are legacy. Updating them to support these 6 new headers will be a pain.

<comment><USER30> Chrome will support the legacy apps by maintaining a static-user agent. It just won't be updated when chrome updates. If you want to build NEW functionality that where you need to test support for new browsers, you do that via feature detection.

</comment></comment><comment><USER31> Interesting. We don't use UA to track customers, but it has been invaluable information for trying specific bugs. Eg, twice in the past 2 months, I've had to fix weird bugs that didn't make sense. The only way I was able to solve them was to look for patterns in which browsers and versions those who reported the bugs were using. Both turned out to be to do different iOS Safari cookie related bugs that only occurred in specific versions. Without logging the UA there would have been no way I would have been able to discover those bugs and create workarounds for those iphone users.

I'm all for preventing tracking, but I can't imagine a time where all browsers behavior so similarly that we won't have to write workarounds for browser bugs and differences. As a developer I can't imagine caring about Edgium vs Chrome, but it's important to know what the underlying engines are.

</comment><comment><USER32> New proposed syntax adds even more noise:

        User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
        AppleWebKit/537.36 (KHTML, like Gecko)
                Chrome/71.1.2222.33 Safari/537.36
        Sec-CH-UA: "Chrome"; v="74"
        Sec-CH-UA-Full-Version: "74.0.3424.124"
        Sec-CH-UA-Platform: "macOS"
        Sec-CH-UA-Arch: "ARM64"

Why not getting rid of the `User-Agent` completely?

It's already bad infrastructure design to have the server do different renderings depending on `User-Agent` value.

<comment><USER33> Why the hell does a regular website need to know what OS and CPU architecture I got?

<comment><USER34> I can already see the permission pop ups for those:

> for best performance this website would like to know what type of device you > are using?

While requesting every single "hint" and there is "ok" button and greyed out "read more or declide this request" tiny line.

</comment></comment></comment><comment><USER35> This was recently discussed on HN:

3 months ago: [https://news.ycombinator.com/item?id=21781019](https://news.ycombinator.com/item?id=21781019)

1 year ago: [https://news.ycombinator.com/item?id=18564540](https://news.ycombinator.com/item?id=18564540)

</comment><comment><USER36> From the git repo:

> Blocking known bots and crawlers Currently, the User-Agent string is often > used as a brute-force way to block known bots and crawlers. There's a > concern that moving "normal" traffic to expose less entropy by default will > also make it easier for bots to hide in the crowd. While there's some truth > to that, that's not enough reason for making the crowd be more personally > identifiable.

This means that consumers of the Google Ad stream have one less tool to identify bots, and will pay Google for more synthetic traffic, impressions and clicks; this could be a huge revenue boost for Google. A considerable amount of their traffic is synthetic. I doubt this was overlooked.

</comment><comment><USER37> does this mean there will no longer be a way of determining if the device is primarily touch (basically all of "android", "iphone" and "ipad") or guesstimating screen size ("mobile" is typical for phones in the UA) on the server?

[https://developer.chrome.com/multidevice/user- agent](https://developer.chrome.com/multidevice/user-agent)

i wonder what Amazon will do. they serve completely different sites from the same domain after UA-sniffing for mobile.

is the web just going to turn into blank landing pages that require JS to detect the screen size and/or touch support and then redirect accordingly?

or is every initial/landing page going to be bloated with both the mobile and desktop variants?

that sounds god-awful.

<comment><USER38> Presumably you'll grab the dimensions (could cache after first load) and then render dynamically based on that. If you're doing some sort of if statement on the server to deliver content based on screen size you're probably doing it wrong. Obviously I can't speak for every mobile user, but for myself, it's infuriating to have a completely different set of functionality on mobile.

<comment><USER37> > If you're doing some sort of if statement on the server to deliver content > based on screen size you're probably doing it wrong. Obviously I can't speak > for every mobile user, but for myself, it's infuriating to have a completely > different set of functionality on mobile.

there's not a "right" and a "wrong" here; it's about trade-offs.

you're either stripping things down to the lowest common denominator (and leaving nothing but empty space on desktop) or you're wasting a ton of mobile bandwidth by serving both versions on initial load (the most critical first impression).

you frequently cannot simply squeeze all desktop functionality from a 1920px+ screen onto a 320px screen - unless you have very little functionality to begin with. Amazon (or any e-commerce/marketplace site) is a great example where client-side responsiveness alone is far from sufficient.

[https://www.walmart.com/](https://www.walmart.com/) does it okay, but you can see how much their desktop site strips down to use the same codebase for desktop and mobile.

</comment></comment></comment><comment><USER39> Can't happen soon enough. As a frequent user of various non-mainstream browsers i'm sick and tired of seeing "your browser isn't supported" messages with download links to chrome/etc. At least in the case of Falkon it has a built in user agent manager, and I can't remember the last time flipping the UA to firefox/whatever actually caused any problems. Although, i've also gotten annoyed at the sanctimoniousness web sites that tell me my browser is to old because the FF version I've got the UA set to isn't the latest.

<comment><USER40> if your browser isn't supported, it's not the browser's fault, rather the website you go on not to support your browser.

</comment></comment><comment><USER41> I log this for coarse statistics about what our user base is running, but that is about it.

The good news: IE use is down over the last year to only about 40%.

The bad news: the growth elsewhere is all Chrome, with less than 1% Firefox or Safari. There's a tiny sprinkling of Edge, as well, but I forget the numbers on that.

Our users are state and county offices and medical facilities, rather than private individuals, so the users are somewhat captive to whatever their organization mandates.

The only browser detection we do is in client side scripting to detect if the browser can directly display a PDF inline (or not, in the case of IE11)

</comment><comment><USER42> I would much prefer a new version of the user-agent string. Normalize basic information (like OS and browser versions) without revealing too much (build numbers).

That would let servers still get necessary info without having to run even more javascript. It can just be in querystring format to simply parsing on both client and server.

<comment><USER43> Any user agent string will eventually be forced down the same path. Web sites use them to deny content. And the browsers will continue to try to match more patterns so their users see the content.

As long as they exist, I can see no escaping this arms race.

</comment></comment><comment><USER44> Larry Page no longer wants to be a "good net citizen"?

[https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJ...](https://groups.google.com/forum/m/#!msg/comp.lang.java/aSPAJO05LIU/ushhUIQQ- ogJ)

</comment><comment><USER27> I view this as an attack on the web as it stands.

Google wants to create a walled-garden net. Goog-net. All ads, shopping, videos, documents, email, locations, articles flowing through THEIR protocols and THEIR servers and THEIR fiber. No possibility of blocking ads they don't want blocked. No URLs. No Agent strings. No user control. Only user consumption.

If they have to allow some small chump players to have a piece of this cake (a la: "Oh trust us, AMP is an 'open' protocol and anyone can host it. it's not just for our own benefit in the end. Trust us.") in order for the entire population to accept their changes bit by bit, so be it in their eyes. They know we would reject an outright takeover.

</comment><comment><USER45> This is OK...I guess? I mean it's great to get rid of that overloaded carbuncle of user-agent, but that will just lead to a new round of interpreting "hints". _shrug_

Google is a serial abuser of user-agent already so this is somewhat ironic.

</comment><comment><USER46> The first time one of my articles appear in HN, I'm kinda excited

</comment><comment><USER47> Fantastic. Thank you Chrome team! Especially for those who dont execute arb JS, this is a huge +.

Personally, I would like to drop the line completely and not send the key at all, but it's a start.

<comment><USER48> totally agree!!!

</comment></comment><comment><USER49> So Google found good way to fingerprint users without user agent and found that a lot of user agents are forged and this stopped working anyway. It's time to switch to API support forging.

</comment><comment><USER50> User-agent is super useful to human people. But corporate people don't have a use for it. They will get that information via running arbitrary code on your insecure browser anyway. So, because mega-corps now define the web (instead of the w3c) this is life.

But it doesn't have to be. We don't have to follow Google/Apple-Web standards. Anyone that makes and runs websites has a choice. And every person can simply choice not to run unethical browsers.

<comment><USER43> > User-agent is super useful to human people.

For what? Honest question. You have to be like a 5th-level user agent wizard to make any sense of user agent strings, since every browser now names every other browser. How do you do anything useful with this in a way that's forward-compatible?

<comment><USER50> I look at the logs of my websites with my eyeballs manually after a perl script to winnow them down (ie, remove hits form me, hits from tor, etc).

</comment></comment></comment><comment><USER51> This is insane. You know, no HN post to a google blogspot site works for me because these jerks are the only ones that discrinate on UA?

Google engoneering is Sooooooo disconnected from the rest of the world, I think we need legal regulation to stop them from doing stuipd things like this. Do they have any idea how many things need it?

HNers with a position of power at work, I plead with you: please advocate banning of Chrome at work and replacing it with any one of the webkit based alternatives or firefox. These people are insane. Every month I hear of some ridiculous thing. They took out navbar url parameters, add links to in page words, now this!

For those who think this is good for privacy...it is not! This is the same old sneaky ass evil thing they do. UA can be used to finger print you but it's very easy to set a generic user agent. Actually, if you look at user agents most of them have the latest string for Chrome, IE or firefox so it isn't useful without a whole lot of other details correlated with it. You know what the exception is? Android and iPhone browsers that incluse your device make and model in the UA and apps that includes whole lot more like facebook's apps.

Do you know what a "flexible" api like the one they're talking about allows? More fingerprintable data points! The fact that you even use that api is a privacy issue. Let's sat clienthints allows for 10 different variations of responses from clients,your specific client details might have just 3 things different from the mean and bam, now they can track your specific device. With UA,all versions of a client have the same exact detail and most people need an extension to change it, so it makes it much less easy to finger print.

This is the same ol sneaky bait and switch Google pulls. The content of your UA is not the privacy concern (although it contains too much at times) , it is the fact that it can be correlated with timing info,IP (especially v6),and if they already know your UA they will also use client default http header options to identify and track you without consent.

</comment><comment><USER52> Any idea on how to identify devices then? We currently check the user agent to to send a new code when an user logs in from a new device. How would you do this without user agent?

<comment><USER53> Use a cookie?

</comment></comment><comment><USER54> This change does not remove the user agent. In practice it just hides OS and the version but the user may opt-in to send those to a particular site.

</comment><comment><USER55> Ah, the end of the countless references to KHTML :)

As a long time KDE user I'm a little sad, but also fully aware this day would come.

<comment><USER56> How can we use a browser that doesn't pretend to be Netscape Navigator? This will never work :)

</comment></comment><comment><USER57> if you want to go to the source of that story:

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...](https://groups.google.com/a/chromium.org/forum/#!msg/blink- dev/-2JIRNMWJ7s/yHe4tQNLCgAJ)

</comment><comment><USER58> I was wondering. Isn't the page rendered on mobile and desktop based on user- agents? How would that work now?

<comment><USER59> I thought it used Javascript to detect screen size. At least it should react to resize events and if the dimensions are something that align with mobile, it should switch to mobile mode.

<comment><USER60> In a lot of cases you shouldn't even use Javascript for this, responsive layouts can be built using CSS media queries based on viewport size.

More advanced webapps might occasionally need to do something fancier than that if the mobile vs desktop functionality is (for some reason) substantially different instead of just rearranged.

[https://developer.mozilla.org/en- US/docs/Web/CSS/Media_Queri...](https://developer.mozilla.org/en- US/docs/Web/CSS/Media_Queries/Using_media_queries)

</comment></comment></comment><comment><USER48> Finally someone step up to stop the UA madness!!!

Now, all we'll need is a way to not send anything at all!!!

</comment><comment> CKN23-ARIN > While removing the User-Agent completely was deemed problematic, as many > sites still rely on them, Chrome will no longer update the browser version > and will only include a unified version of the OS data.

So, nearly all of the information that makes User-Agent strings problematic will remain. They're just phasing out precise version information.

</comment><comment><USER40> isn't it concerning that Google decides to follow and implement even though the conversation on github concluded by "it should be rejected by W3C"?

</comment><comment><USER61> So basically, Google shat their own bed and is just now beginning to realize that it stinks. Attempts to invent the universal internet user toll booth are back on track.

</comment><comment><USER62> Stupidity. user-agent spoofing is a fact of life for many projects. Whatever feature they're going to come out with to replace UA will be spoofable too soon enough.

</comment><comment><USER63> sorry, anyone knows the link of the original source of this?

</comment><comment><USER64> No! I loved User-Agent because I could fake other user agents, e.g.

\- being the google crawler to get past paywalls

\- being a Mac user agent to get free internet access at some hotels

</comment><comment><USER65> ahhh

</comment><comment><USER66> More specifically, Google thinks they're the central authority as to what Chrome will do.

</comment><comment><USER67> If they're the dominant web browser people will assume you are using Chrome anyway.

</comment><comment><USER68> Annoying, as I just added a user agent based workaround for another Chrome compatibility problem (the increased security on same-site cookies, which can't be handled in a compatible way with all browsers).

</comment><comment><USER69> Because, there can be _only one user agent_...!

</comment><comment><USER70> As usual, this will fuck up the users, and not the techy nerds making such decisions, but the average joe because things on the internet will be broken for them.

<comment><USER8> How will things be broken? Google is not removing the user agent, they're just freezing it. So all sites that currently depend on the user agent will continue to do just fine. New sites can use client hints instead, which are a much more effective replacement for user agent sniffing.

This solution very specifically places the burden on "techy nerds" and not users, so I'm not sure where you're coming from.

<comment><USER71> Right, using user agent on the client side has been unsalvageably broken for a long time. Other things, like checking the existence of window.safari or window.chrome are more reliable.

For the server side, I'm not too aware of too many cases it's useful other than analytics, and there is too much info leakage and fingerprinting happening anyway.

So killing user agent doesn't really seem user-hostile, save for the fact that the company doing it has near monopoly market share and doesn't _need_ to provide a user agent, as it's assumed that everyone is writing code to run on Google's browser. In that sense it's a flex.</comment></comment></comment>


Effects of Political Partisanship and Advertising on Family Ties [pdf] - <AUTHOR> https://economics.stanford.edu/sites/default/files/sharable_fulldraft.pdf <comment><USER2> This sentence alone should suffice for an ig Nobel nomination:

 _we estimate 27 million person-hours of cross-partisan Thanksgiving discourse were lost in 2016 to ad-fueled partisan effects._

</comment><comment><USER3> All: the title contains the word "political", but if we cleave to the actual content of the paper we might stand to learn something. Partisan bickering is right out, of course.

</comment><comment><USER4> One thing that jumped out at me is that they cite an increasing number of party members hating the other party. What they don't consider is that party membership for both parties has declined over the same time period, presumably leaving the most partisan in the parties. So it doesn't seem unlikely that the very premise of the work is inaccurate.</comment>


Free Download: Foundations of Machine Learning, Second Edition - <AUTHOR> https://cs.nyu.edu/~mohri/mlbook/ <comment><AUTHOR> Direct PDF Link: [https://www.dropbox.com/s/7voitv0vt24c88s/10290.pdf?dl=1](https://www.dropbox.com/s/7voitv0vt24c88s/10290.pdf?dl=1)

Notes:

A new edition of a graduate-level machine learning textbook that focuses on the analysis and theory of algorithms.

This book is a general introduction to machine learning that can serve as a textbook for graduate students and a reference for researchers. It covers fundamental modern topics in machine learning while providing the theoretical basis and conceptual tools needed for the discussion and justification of algorithms. It also describes several key aspects of the application of these algorithms. The authors aim to present novel theoretical tools and concepts while giving concise proofs even for relatively advanced topics.

This second edition offers three new chapters, on model selection, maximum entropy models, and conditional entropy models. New material in the appendixes includes a major section on Fenchel duality, expanded coverage of concentration inequalities, and an entirely new entry on information theory. More than half of the exercises are new to this edition.</comment>


Diagnosing and Fixing Memory Leaks in Python - <AUTHOR> https://blog.fugue.co/2017-03-06-diagnosing-and-fixing-memory-leaks-in-python.html <comment><USER2> Of course, as a user of Requests in what could be a similar use pattern my question now is: Is this an actual bug in the requests library, or some strange interaction with your app? Was a bug report filed I could follow?</comment>


Evgeny Morozov on the exaggerated fears over digital warfare - <AUTHOR> https://bostonreview.net/us/cyber-scare-evgeny-morozov <comment><USER2> (2009)

Worth noting that since then, there have been some pretty high profile attacks on industrial control systems (Stuxnet, BlackEnergy, to list the big ones)</comment>


Show HN: Android Toggle Switch an Extension of Android Switches for 2+ Items - <AUTHOR> https://github.com/BelkaLab/Android-Toggle-Switch <comment><AUTHOR> If you have any suggestions or critiques let me know about that!

<comment><USER2> I didn't see the images at first and wasn't sure what it actually was, mentioning the iOS alternative `UISegmentedControl` would have helped me there.</comment></comment>


What C/C++ repo do you work on (github/bitbucket/etc)? - <AUTHOR>

<comment><USER2> Well, since you're volunteering... this is C rather than C++, but if you're interested in GStreamer (media processing library) and OpenCV (computer vision / image processing) then you could have a go at improving the motion-detection visualisation of our "stbt-motiondetect" gstreamer element.

If you're interested send me an email for help getting started, and see the 2 latest commits on [https://github.com/drothlis/stb- tester/commits/motiondetect_...](https://github.com/drothlis/stb- tester/commits/motiondetect_visualisation)

<comment><AUTHOR> enjoying reading <http://david.rothlis.net/c/compilation_model/>

will get in touch, when i'm done with ^

<comment><USER2> Thanks! :-)

</comment></comment></comment><comment><AUTHOR> Just submitted my first pull request to a C++ repo on Github, and loved the experience.

link <https://github.com/duckduckgo/cpp-libface/pull/6>

if you would like contributions from someone who predominantly works on objective-c, but wants to learn & dig deeper into c/c++ on weekends, do list them here or ping me!

~B

</comment><comment><USER3> not as Sublime as the WhiteAlbum number9 ,Julia Fork github?</comment>


Ask HN: Is Philosophy any different from fiction? - <AUTHOR> Can you <i>formally</i> verify philosophical concepts? What would it mean to verify Idealism, for example? Would love to hear peoples thoughts on this. Been racking my head for ages on it and can't come up with something sound and complete. <comment><USER2> [https://en.wikipedia.org/wiki/Pragmatic_maxim](https://en.wikipedia.org/wiki/Pragmatic_maxim)

<comment><AUTHOR> ohhh. Thank you :)

</comment></comment><comment><USER3> If you want to formally verify a concept, you need a framework, or reference concepts: axioms.

<comment><AUTHOR> So what are the axioms for Western philosophy?

EDIT: Ludwig Wittgenstein's work is pretty axiomatic right?

<comment><USER3> There is no "western" philosophy. It's not a block.</comment></comment></comment>


Why programmers work at night [2011] - <AUTHOR> http://swizec.com/blog/why-programmers-work-at-night/swizec/3198?

<comment><USER2> Hmm this article lacks any sources. Otherwise, a decent propaganda piece.</comment>


The Next-Gen Drive-Thru Is About AI, Not Mobile Ordering - <AUTHOR> https://thespoon.tech/the-next-gen-drive-thru-is-about-ai-not-mobile-ordering/ <comment><USER2> Fluff piece almost devoid of content; a quasi-submarine for industry executives that namedrops a few companies selling fancy point-of-sale tech.

The two important points made in the article are that fast food places have issues with timing mobile orders, and many store managers notice that mobile pickup facilities are overprovisioned relative to their usage.

The first is a solved problem in the world of takeout pizzas; in fact, such pizza places often have minimal storefronts and waiting space. But pizza keeps well in a box under its own heat, and heatlamps have become unfashionable in fast food as everyone wants to move upmarket and made-to-order. But there's also a UX solution: detect or ask the customer via the app when they're ready for the order to be made.

The second point is ironic: all these companies pushed into mobile ordering as a top-down directive thinking that's what users want. They'll push into AI or whatever hype next the same way. It's bullshit. People want low prices (McDonald's, Taco Bell), or they want the appearance of quality (Panera). Blowing a ton of money on some half-baked ML ordering system is a waste, when they've already cut their cashiers by putting up slow kiosks and put all their ordering UI on everyone's phone. But the people selling this to clueless executives spinning their wheels stand to make a decent chunk of change until they cash out to some equally-clueless established point-of-sale company.

<comment><USER3> I suppose you could even use some basic ML (or hell, just geo-location and expected arrival) get an idea of when to prompt the restaurant to "start making XYZ order" when it appears the customer is driving in the direction of the restaurant. Though this does potentially doesn't make since if your gym is right next to the burrito shop, and you end up with a cold burrito!

<comment><USER4> This is exactly what the larger chains are trying to accomplish.

Let's take McDonald's as an example. I've worked there as a crew member and, many ironic decades later, currently assist some of their OEMs in the kitchen equipment area.

McD has always been a JIT-based manufacturing/assembly company. And their production window isn't a week or a day: it's 10 minutes. Back in the old days when you walked in and there was a bin full of burgers, those were all made to be sold or tossed after 10 minutes. How do you manage that without wasting a single burger?

Managers would keep insanely detailed logs of sales by the hour or even half- hour to try and assemble some kind of historical record that could be used to anticipate future demand. They would even record the traffic level outside and weather conditions. It worked pretty well, but one rogue schoolbus full of hungry teens would blow that forecast out the window.

The newer systems try to smooth some of that out with heated holding cabinets and faster toasters and et cetera, but there are some things you really can't batch and hold for very long, like fries. Customer demand has also required some of the batched systems go away, like the Quarter Pounders being grilled as they are ordered.

So when a batch of fries takes 5 minutes to cook, and you know there's a wave of people arriving, _any_ technique to help anticipate that and trigger a production cycle sooner is ideal. It benefits producer and consumer alike.

Mobile ordering isn't a panacea, and in fact the current system isn't very usable at all. But they're trying. And I do know second-hand that they're aware of geofencing but there are complications to a system like that as well.

</comment></comment></comment><comment><USER5> Mobile ordering has never made sense. It's easier to just tell a person what you want when you actually get to the drive-thru, not to mention fresher. You don't have to make an account or input payment information or download an app. Just speak and then hand a small plastic rectangle to them.

This AI BS is just a scam designed to dupe clueless executives out of their money. It's just window dressing. The real problem? Constant delays in the drive thru. People can order just fine already, what pisses them off is sitting in the drive thru for 10 minutes waiting for "fast food". Not to mention the price increases and a lack of new novel menu items.

<comment><USER6> Where does the customer's vehicle go between ordering and pickup? Some places have an order station followed by a waiting lane of N car lengths to the pickup station. That limits throughput to 1/N prep times. More waiting lane space costs real estate. It also means you can't sell anything with a long prep time.

So the temptation for fast food sellers is to make customers order ahead. This is an economy for the store, not a convenience for the customer. Thus, efforts to encourage or coerce customers to order online.

This leads to a proliferation of ordering apps, all different. That will be followed by consolidation: "Uber Eats", "Amazon Fresh", "Google Chow".

</comment></comment><comment><USER7> > Apprente makes interactive machines powered by a proprietary, neuroscience- > based AI technology.

They say mobile ordering is bad, so the solution is AI ordering, and a touch screen.

<comment><USER8> > neuroscience-based AI technology

Is this just a journalistic misinterpretation of neural networks?

</comment></comment><comment><USER9> Dumb. Fast food is dying because people don't want mass produced food that's been sitting in a warehouse frozen for months. Automation is a race to the bottom in fast food, which will only accelerate its decline even if it can marginally reduce costs.</comment>


Proximal Policy Optimization for Playing Super Mario Bros - <AUTHOR> https://github.com/uvipen/Super-mario-bros-PPO-pytorch <comment><USER2> How far away is this from the top speedruns? The readme mentions OpenAI beating Dota 2 pros with the same models, so who knows??

It seems like an AI would not "play by the rules" and can easily detect weird edge cases and shortcuts. But as far as I can tell from the small GIFs, it's not doing any particular glitches.

<comment><USER3> It can't complete all the levels and actually does worse on the first level than a normal human (for example falling down a hole and having to get out again).

So it's quite far from a speed run.

</comment></comment><comment><AUTHOR> Original paper: [https://arxiv.org/abs/1707.06347](https://arxiv.org/abs/1707.06347)

Disclaimer: I am not the creator.

</comment><comment><USER4> Does this somehow include the ROM for the game and an emulator?</comment>


Ask HN: Virtual HSA (Healthcare Savings Accounts)? - <AUTHOR> It seems my personal banks are no longer offering HA accounts. My employer uses a bank, but the nearest branch is a days drive away from me and that's just to sign paperwork.<p>Does anyone know of a "virtual HSA" one can get? I was hoping that Bank Simple had one but they don't offer anything yet. <comment><USER2> I've been happy with Lively. I was able to sign up quickly and they made transferring my existing HSA over really easy.

Here's my referral code if you want to give it a shot:

[https://secure.livelyme.com/referral/invite/?referrersOwnerI...](https://secure.livelyme.com/referral/invite/?referrersOwnerId=6740ac53-9fd2-43d1-9b42-efab4579b00b)

<comment><AUTHOR> Thanks. I'll check them out this weekend. Thanks for the referral code!!

<comment><AUTHOR> I did indeed sign-up with Lively. A few minor hiccups with their iPhone app but things still worked out.

</comment></comment></comment><comment><USER3> State Farm, Aflac (I'm pretty sure I had an HSA when I had Aflac), other supplemtal insurance like Aflac.</comment>