Pot.js is a utility library that can execute JavaScript without burdening CPU. - <AUTHOR> http://polygonplanet.github.com/Pot.js/test-for-new-design/#manual.overview <comment><USER3> I may be missing something, but it seems like the purpose of this library is to solve the problem that if you run too much code in javascript in the browser at any given time you can hog the application thread long enough that it makes the user interface lag. So you can break up your operations into chunks that will be executed in order. This library will help you run functions in order and not all at once without having to use callbacks and setTimeout(function(){...}, 1).

</comment><comment> mike-cardwell What exactly does this do? I've read the overview and introduction and can't figure it out...

<comment><USER4> I will take a guess:

One central reason why JavaScript can lag a page is that an infinite loop can occur in any function. Javascript is single-threaded, so this won't just slow down your computer; it can potentially crash your browser. Nothing else is allowed to happen until this function exits; if the function never exits, then the page is stopped and in some cases the whole browser process is stopped.

We could instead schedule these loops. That means that we'll check for browser events first before we go to the next thing in the loop. Here's some code which does this, implementing a simple for-loop structure:

        function loop(start, end, fn) {
            if (start < end) {
                setTimeout(function () {
                    fn(start);
                    loop(start + 1, end, fn);
                }, 0);
            }
        }
        loop(0, 1000, function (i) {
            // do some complicated calculation.
        });

Is this what Pot.js does? Well, it implements a deferred "forEach" function, but if that's the goal, then that is not very clear -- especially because the main provided example (getting JSON) is already an asynchronous task in most implementations.

If that _is_ the goal of Pot.js, then the library is an example of premature optimization and probably should not be used in new projects until it's determined that some loop is actually slowing down the page somehow. There are many reasons for this, but the simplest is that scheduling a function tends to kill a stack trace, and stack traces are more useful.

Unfortunately, the real use case probably isn't covered. The real case where I accidentally crash Firefox sometimes comes when I'm developing recursive functions. Consider this implementation of the Fibonacci numbers:

        function fibs(n) {
            return n <= 1 ? n : fibs(n) + fibs(n - 1);
        }

Do you see the bug? It calls fibs(n) when it evaluates fibs(n), and goes into an infinite loop -- instead it should call fibs(n - 2). It's the sort of mistake that can crash Firefox if accidentally coded in Firebug.

Here is how the program would need to be structured if I wanted a magic protect() function to protect myself from Firebug crashes. Notice that everything needs to be made very ugly by wrapping it in callbacks:

        var fibs = protect(function (n, callback) {
            n <= 1 ? callback(n) : fibs(n - 1, function (u) {
                fibs(n, function (v) {
                    callback(u + v);
                });
            });
        });

Now, this function protect() can schedule the functions and while this _will_ loop to infinity, it _won't_ crash Firefox and I can copy important data to a text document before closing the tab.

Unfortunately, the above is so ugly that I will probably never be willing to write it again. So I also don't see the point here.

</comment></comment><comment><USER5> Just a small warning: don't click the menu items too quickly in chrome - <USER2> gets stuck in a loop scrolling back and forth.. Whether this is due to Pot.js or not I cannot tell without delving deeper!

<comment><USER6> And just like that, you determined my experience on this site :) Confirmed to occur in firefox as well.

I actually don't know anything about pot.js now except that this bug scares me.

</comment></comment><comment><USER7> > JavaScript のループ処理における CPU 負荷を抑え、UI にストレスを与えることなく実行できるライブラリです。

I definitely should improve my japanese skills a bit. ;)

<comment><USER8> Is not u. The doc is not clear enough... :P

</comment></comment><comment><USER9> Note, that you can change the language using the little link titled "en" in the upper right corner.</comment>


SpaceX Layoffs Include Positions at California Headquarters - <AUTHOR> https://www.bloomberg.com/news/articles/2019-01-13/spacex-layoffs-include-577-positions-at-california-headquarters <comment><USER3> Looks like no engineering jobs, but mostly technicians and assembly. This makes me think the launch cadence of 2019 is taking its toll.

<comment><USER4> Why? The whole point of reuse was that you dont need so many boosters for so many launches. The will keep building new once but they are no longer production constraint.

<comment><USER3> Because the types of jobs I mentioned are mostly for prepping the launch vehicle, the launch site, and all the logistics surrounding that. If they aren't launching nearly as many, then they don't need as many of these people. engineering still needs to be there to make the next rocket.

</comment></comment></comment><comment><USER5> Earlier discussion: [https://news.ycombinator.com/item?id=18888641](https://news.ycombinator.com/item?id=18888641) (500+ comments)

</comment><comment><USER6> Sending everyone home and then waiting to find out if you have a job via email sounds terrible. Does anyone else do this?

<comment><USER7> Not sure if this is better but I heard of people coming into work and no one is able to log in to find out that half the staff is being laid off. Also I have heard where you can't badge in one morning and then security escorts your to HR. This is prevalent particularly in the defense industry since they are worried about sabotage. Though this is all hearsay from Senior Mechanical Engineers that I met throughout my years. I have been warned many times to only bring enough to work where you can carry out in a box. I know colleagues who had their stuff in a plastic tote at all times (like valuable reference books) so they are always ready to leave at any time.

</comment></comment><comment><USER8> I'm really not sure I understand this layoff, will they be cancelling some of the projects?

<comment><USER9> The launch market for commercial customers is very small, and any hint of economic downturn hits capital asset investment (ie satellites) proactively. To me, this sounds like another ominous indicator of an imminent economic downturn.

<comment><USER10> This is more an indicator that almost everything that needs to go up, has already gone up.

Notice that one of SpaceX's largest clients, Iridium, just completed their new constellation. That was eight Falcon 9 launches. Iridium is done, they don't need any more launches. Likewise for other large SpaceX clients.

<comment><USER11> On a totally unrelated note, I wad thoroughly surprised at how cheap satellite internet has become. If you spend $300 on a Garmin device and $50 a month, you get unlimited global text messages receiving/sending.

Considering that I spend $30 a month for Verizon prepaid, where the cell coverage is _hilariously_ spotty and data is 1kb/s, an extra $20 a month seems entirely worth it, especially if you go off the beaten path like I do in random countries.

Hooray commerce!

<comment><USER12> From their point of view, their SMS capacity is effectively unlimited, so the marginal cost of having you as a customer is zero.

Since there are no real competitors, pricing simply becomes 'maximize the area under the price-demand curve'.

<comment><USER11> If the entire world was sending text messages through their satelites, they wouldn't really have a bottleneck?

Not even trying to start an argument, I didn't think they had that much bandwidth. I suppose they do voice calls but definitely not video or pictures?

I would be thoroughly, thoroughly, infinitely pleased to switch to a satellite only texting service. I've been seriously considering just making the switch now and porting all of my news consumption habits to text files that are texted to me.

Their lowest tiers I think are 19.99 a month but only allow 10-40 text messages?

<comment><USER12> Quick back of the envelope calculation... Lets assume 10 texts sent per person per day worldwide on average. Lets also assume everyone has a phone (far from true, but hey). Assume an SMS message is 160 bytes, but with compression is significantly less, but there is also connection/presence metadata - <USER2> cancelling out. So we have 1600 bytes * 7 billion people. Thats spread across 66 satellites. That totals 2 megabytes per satellite per second. Very doable.

<comment><USER11> I'm going to contact them about a texting only package where they disable voice capability and you have to oay one year upfront at like 20 bux a month!</comment></comment></comment></comment></comment></comment></comment></comment>


Calling Windows 10 APIs from a WinForms or WPF application - <AUTHOR> https://blogs.windows.com/buildingapps/2017/01/25/calling-windows-10-apis-desktop-application/ <comment><USER3> Look at this screenshot of context menus in Windows 10 [https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large](https://pbs.twimg.com/media/C2Y6rwoXEAAaQll.jpg:large) win32, MFC, WinForms, WPF, Web.. Why don't stick to 1 framework and make it work good, deprecate rest, why have multiple buggy and ugly. If compare HTML/CSS and WPF improvement over last 15 years it is 10000 to 1. WPF could have been great 5 years ago, but I'm not sure it ever will be.

<comment><USER4> The simplest answer is that Microsoft's software mimics the design of the organization with multiple fifedoms building their own toolkit, causing fragmentation.

We already know that the Office and Windows teams have different GUI toolkits from reports from inside the company. But there is evidently a lot more fragmentation than just those 2 groups.

What I find more interesting is that Google products are starting to feel similarly fragmented. Project fi, Android, Plus, and Search all look and behave differently. My damn phone gets SMS on Hangouts and the Messenger app, my voicemails come on the phone and hangouts. None of it makes sense.

We can all agree that inconsistent GUIs are bad, but it seems like a problem you have to solve from a top down organizational perspective, which might not obviously align with the business.

<comment><USER5> The Excel team even has their own compiler!

<comment><USER6> The problem is that they keep compiling the same version of Excel, just changing a little bit the color scheme each time.

<comment><USER7> Word, Excel, PowerPoint were all coded between 1989 and 1993. And received major update with Word 6 and Office 95 and 97. Basically Office 97 was feature complete. Very little has changed since then. The ribbon bar and all the other minor increment improvements are really minor compared to the changes up to Office 97. Office uses it's own UI library. Using Word 6 in Win95 shows floating toolbars in Win3.1 UI theme. Office 95 had an italic title bar. Using Office 97 in WinXP or Win7 shows and Win95 UI theme.

<comment><USER8> Well, MS removed quite a few ridiculous features from the Office 97 days. Like auto summary or Cliparts.

<comment><USER6> But removed some quite useful features at the same time, like the ability to customize the UI by moving the most frequently used buttons to the front.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I absolutely love WPF development.

I'm all web now, and I love it too, but sometimes I just wish I could go back to the good old WPF days!

The extensive tooling involved with frontend web development and the constant religious wars between frameworks can get exhausting.

<comment><USER10> Why not port WPF to the web?

<comment><USER11> I have a better idea, drop JavaScript from Web and leave it as pure HTML/CSS.

<comment><USER12> It's as easy as disabling it in your browser options. You can purify your own web in seconds!

<comment><USER11> It doesn't help if the web site is JavaScript only!

<comment><USER12> Pure html/css can't do everything javascript can. You can't have it both ways.

<comment><USER11> Of couse it can't, that is the whole point.

The web should be HTML/CSS for hyperlinked documents only, for everything else native apps.

<comment><USER12> Where should that be enforced? Browsers? Web servers? Firewalls? If you believe the answer is browsers, you can make that change today. Obviously, others don't agree with you. Why should their web experience be limited by your unsupported point of view? You haven't really made a great case.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> As a user i find going the other way more troubling.

Say i want to use a UWP file manager on Windows 10. Out of the box the folders i can access are limited, and adding more require that i use the age old Win32 file picker window.

Similarly both Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default one. Something that is not always desirable.

So from a user perspective, UWP feels bolted on rather than a integrated part.

<comment><USER14> I find UWP pretty terrible. :( It feels like developing for a weakest link (the traditional cross-platform problem) which is often Windows Phone or something. Which doesn't exist!! Windows Phone doesn't bloody exist! If MS had amazing mobile market penetration UWP would be amazing but what is this?! How is UWP exactly better than WPF for Windows desktop apps? It isn't. But it's where MS now wants you to be, because they have crazy deeams.

<comment><USER15> WPF has a dependency on the CLR which made it a non-starter for the Windows and Office teams. That's the main reason WinRT/UWP XAML was developed in the first place; they wanted a developer platform they could use themselves, and those teams are unlikely to adopt C# anytime soon.

<comment><USER11> Actually WinRT/UWP are the Longhorn ideas, using the original design of .NET, originally known as COM+ Runtime.

Also a reason why .NET is AOT compiled to native code on UWP.

<comment><USER15> Right, they tried adopting C#/XAML for the shell and Office with Longhorn, and when that project failed they decided to essentially reimplement WPF and .net in native code, e.g.

WPF text stack -> DirectWrite

WPF visual layer -> Direct2D, Windows.UI.Composition

WPF UI layer -> WinRT XAML

.net type system/metadata -> WinRT metadata

CAS/partial trust/other .net security stuff -> AppContainer

ClickOnce -> AppX

If you compare what .net was supposed to be around 3.0 with what .net Core is now, they've basically stripped out all of the "OS-like" stuff - <USER2> frameworks, app model/packaging, security - and taken the stance that those are the responsibility of the OS. UWP is just the Windows native implementation of the stuff that was stripped out of .net to be left up to each OS

<comment><USER11> I always thought that .NET should have been AOT compiled to native code since day one, not the JIT/NGEN mix, given Anders experience with Turbo Pascal and Delphi.

But as someone that follows Windows development since 3.0, and had the pleasure to being introduced to Oberon, I think one of the biggest reasons for Longhorn's failure was the wars between DevTools and WinDev.

To build on your mappings, many other components shown up as COM in Vista and since then the majority of Windows APIs are actually COM based, not Win32 C style ones.

Reading the paper about Ext-VOS, .NET's genesis, and doing the comparisasion with how WinRT looks like, was quite interesting.

</comment></comment></comment></comment></comment></comment><comment><USER16> Similar tricks[0] can be used on Win32 applications.

Although, I never got Intellisense working in VS if I declare #using <windows.winmd> in C++/Win32 projects.

A simpler and a lot more interesting alternative (for Win32) is the excellent cppwinrt library[1]

[0] [https://software.intel.com/en-us/articles/using-winrt- apis-f...](https://software.intel.com/en-us/articles/using-winrt-apis-from- desktop-applications)

[1] [https://github.com/Microsoft/cppwinrt](https://github.com/Microsoft/cppwinrt)

<comment><USER17> The article has Win32 examples too.

<comment><USER18> Using C++/CX (as seen by ref new).

cppwinrt is ISO C++.

<comment><USER17> You can use Windows Runtime Library (WRL) instead of C++/Cx.

[https://msdn.microsoft.com/en- us/library/hh438466.aspx](https://msdn.microsoft.com/en- us/library/hh438466.aspx)

</comment></comment></comment></comment><comment><USER19> Some Apple docs for comparison: [https://developer.apple.com/library/content/samplecode/Metal...](https://developer.apple.com/library/content/samplecode/MetalGameOfLife/Introduction/Intro.html#//apple_ref/doc/uid/TP40017382-Intro- DontLinkElementID_2)

<comment><USER20> What inference should I draw from the comparison to Apple docs? Also aren't you comparing a blog post to docs? (Apples and Oranges)

</comment></comment><comment><USER21> My only concern would be supporting older versions of windows while utilizing features where available. Would have been cool to see an example of doing this in the article.

Just the same, it's cool that it can be added without having to completely migrate/rework an application.

<comment><USER17> The Windows 10 API provides API availability checks. So you target the latest version but then add checks to see what API's are available.

This is nice because it encapsulates both OS version API differences and device capabilities.

[https://blogs.windows.com/buildingapps/2015/09/15/dynamicall...](https://blogs.windows.com/buildingapps/2015/09/15/dynamically- detecting-features-with-api-contracts-10-by-10/)

        using Windows.Foundation.Metadata;

        if(ApiInformation.IsTypePresent("Windows.Media.Playlists.Playlist"))
        {
            await myAwesomePlaylist.SaveAsAsync( ... );
        }

        if(ApiInformation.IsApiContractPresent("Windows.Media.Playlists.PlaylistsContract"), 1, 0)
        {
           // Now I can use all PlayList APIs
        }

<comment><USER22> Unfortunately that's a Windows 10 API, meaning it isn't very useful for older versions of Windows!

<comment><USER17> In that case, you put your Windows 10 stuff in a different .dll that doesn't get deployed on old versions of Windows.

The article has an example.

</comment></comment></comment></comment><comment><USER23> Except the Native API and it's high performance timers!</comment>


Stack Overflow is down due to an attack - <AUTHOR> https://twitter.com/StackStatus/status/836384503354568705 <comment><USER2> That's sad. :(</comment>


Microsoft hires designer behind "The Next Microsoft", Andrew Kim - <AUTHOR> http://www.minimallyminimal.com/blog/msft <comment><USER2> Poor kid. I bet he even believes he can make a difference. He's gonna get eaten up and spit out by the behemoth. In a few years he'll be as bitter and jaded as the rest of us.

[http://www.bonkersworld.net/images/2011.06.27_organizational...](http://www.bonkersworld.net/images/2011.06.27_organizational_charts.png) When this image came out I saw it posted by over a dozen MS friends (in xbox no less) laughing/crying over how true it was.

<comment><USER3> This is supposedly an MS-produced parody of it's marketing efforts. It's very old now (I think it uses a 1st gen iPod?) but is still worth a laugh:

<https://www.youtube.com/watch?v=EUXnJraKM3k>

Thankfully MS have learnt a lot of lessons since.

<comment><USER4> A few days ago, a Microsoft employee who has worked on Windows 7 and 8 said on a Reddit AMA:

"There is no doubt that we have catching up to do. We even do funny ads acknowledging how bad we were: <http://www.youtube.com/watch?v=lD9FAOPBiDk> "

They still know they're not perfect but they seem to think they're good enough already. I hope one day they learn to do things right.

<comment><USER5> This: <http://karaokewebstandard.org/> (from the video) is actually pretty funny.

<comment><USER6> I wonder if anyone has thought of starting a Github repo of a JS library that follows the pattern defined on the Karaoke Web Standards site? Could be a fun project. Using the plethora of HTML5 API's available, I wonder if you could get close to a working karaoke prototype using HTML5 audio and video API's?

</comment></comment></comment></comment></comment><comment><USER7> Designers often come up with such kinds of "unsolicited advice", hoping to get noticed by the big companies, and it's actually the first time I see someone succeeding in this approach (which is a good thing I guess).

What strikes me is that he will be working in the Xbox division, which I already consider Microsoft's most coherent and elegant division, marketing- wise.

Andrew Kim has come up with a _branding_ concept, but I wish Microsoft would have also considered approaching the guy behind this Windows UI concept: [http://www.theverge.com/2012/2/24/2822891/windows-desktop- ui...](http://www.theverge.com/2012/2/24/2822891/windows-desktop-ui-concept) Apart from the fact that it looks gorgeous, I believe it embraced the "flat design"concept in ways that Windows 8 has failed to elaborate.

<comment><USER8> That's basically a direct rip of the Zune desktop software [1] applied to other apps. Windows Phone distinctly reminds me of the Zune HD UI once you're past the live tiles home screen. If they wanted to do more like that, they would only need to turn to their own people that made it. While Zune failed as a product, its team seemingly inspired everything Microsoft's designed since.

1: <http://i.imgur.com/gb2DhNt.jpg>

<comment><USER9> I disagree completely. That looks like an old and dated website and still has loads of unflat.

<comment><USER8> The Zune software is from 7 years ago, and you can see every element of its design in that blog post (sans-serif typography as UI hierarchy, no title bars, flat minimize/maximize/close buttons, back arrows, neon color bars). It stuck out like a sore thumb against Windows XP and the recently released Windows Vista, yet fits right in with Windows 8 where the exact same elements are used throughout Metro.

<comment><USER9> It's cluttered, has lack of whitespace. Round buttons. Horrible grid. Flat does not mean undesigned.

<comment><USER10> You're missing the point. Whatever nitpicks you have with that design is irrelevant to his speculation that it's the _precursor_ to Microsoft's current UI design language.

</comment></comment></comment></comment></comment></comment><comment><USER11> Link to "The Next Microsoft": [http://www.minimallyminimal.com/blog/2012/7/3/the-next- micro...](http://www.minimallyminimal.com/blog/2012/7/3/the-next- microsoft.html)

And its HN comments: <http://news.ycombinator.com/item?id=4195208>

<comment><USER12> Bleh. Something inherently unappealing about rhomboids, especially when they're framing photographs.

<comment><USER13> Also, the dot on the 'i' is missing.

</comment></comment></comment><comment><USER14> I thought the best part of his "The next Microsoft" was choice of font for the logo- it has a softness that fits the name perfectly but stands out boldly. I always felt MS' sharp, italicized font was inappropriate. Besides, any move away from italics is a good move, imo.

Old font: [http://static.squarespace.com/static/50271a61c4aab6c54f9af5e...](http://static.squarespace.com/static/50271a61c4aab6c54f9af5ee/5028140ee4b0195d2ee37559/5028140ee4b0195d2ee37f6e/1341178784035/1000w)

New font: [http://static.squarespace.com/static/50271a61c4aab6c54f9af5e...](http://static.squarespace.com/static/50271a61c4aab6c54f9af5ee/5028140ee4b0195d2ee37559/5028140ee4b0195d2ee37f70/1341178799513/1000w)

<comment><USER7> Microsoft actually did update its logo recently: <http://en.wikipedia.org/wiki/File:Microsoft.svg>

It's not italicized anymore but I prefer the old one, though Andrew's choice of font is nice as well.

</comment></comment><comment><USER15> Whatever you want to say about Microsoft, they have a pretty solid recruiting pitch. The kid is in for a rude awakening once he starts there though.

<comment><USER16> It's funny how it's so plain to us.

</comment></comment><comment><USER17> Oh, so this is that marketing guy? I wasn't too impressed the first time around. I didn't think his changes would make that much of a difference or actually turn Windows 8 into a big success. When I first read this headline, I thought they hired that guy who remade how their desktop should actually look with the "Metro" design thinking, which was far better than what Microsoft has now. What they have now is basically the Windows 7 Basic theme. They didn't really metrofy anything in it. That's just one of the reasons why Windows 8 looks so incomplete and so disconnected from with its other parts.

</comment><comment><USER18> Does he mean to say Apple has also approached him (products I like, fanboy)? That could be Google too, would make much more sense.

<comment><USER19> He interned a summer at Google, so it's quite possible that he had been approached by them.

</comment></comment><comment><USER20> Market a product whichever way you like. If the core engineering is flaky, the product will always be despised.

<comment><USER21> I disagree. Take Facebook, Twitter or Wordpress. All succeeded despite their original engineering - not because of it.

<comment><USER22> I've always thought Facebook has been awesome. In my experience of the web, they were one of the first websites I used daily that pushed that much ajax.. and I loved it.

</comment></comment></comment><comment><USER23> Been following Andrew for years; this is great news.

For those of you who only know him for the Microsoft branding I highly recommend you read the rest of his blog. I think he's the most promising industrial designer of our generation; the next Ive/Rams.

</comment><comment><USER24> I hope that he shows how to do design _without_ skeumorphics.

Worst thing Steve Jobs ever gave us.

</comment><comment><USER25> Andrew Kim was going to get hired by one of the big companies sooner or later. He's just so ridiculously talented that it had to happen eventualy.

</comment><comment><USER19> I've been following Andrew Kim since 2010 (since his HTC Concept). Andrew's designs and general design sense has always inspired me. Looking forward to great things from Andrew.

</comment><comment><USER26> Inspirational. While I don't always like Kim's work, I admire how he kept putting his work out there, and it paid off.

</comment><comment><USER27> The guy talks about himself in the same breathless manner as Apple's marketing. Hubris comes to mind ...

</comment><comment><USER28> Wow, new ads.

</comment><comment><USER29> I am surprised that his concept totally sucks. Both the font work and the logo. They are so utterly bad, that even I, being just an amateur designer, clearly see how it is bad and where it is bad, and even I could probably make something much better. Apparently, this is the reason why he was hired, as Microsoft is firmly set on the course of sucking.

(By the way, a note for the straightforward thinking folks: the fact that this particular design sucks does not mean the guy is not talented or promising, especially given his young age.)

<comment><USER24> You haven't really told us why it is so bad. I'm curious why you don't like it?

In a team, the design would be pushed and polished by a number of other team members. This was a one man job, on a team he'd collaborate and come up with more awesome designs. He'd get _feedback_ , where in this case he only got people sniping from the sidelines... people like yourself.

<comment><USER29> I've thought of that for a while: if someone doesn't see what's wrong, it's just like they're blind. Obviously, it doesn't make sense talking to them.

<comment><USER24> Let's hope they never put you in front of a client!</comment></comment></comment></comment>


Metro Crash May Exemplify Paradox of Human-Machine Interaction - <AUTHOR> http://www.washingtonpost.com/wp-dyn/content/article/2009/06/28/AR2009062802481.html?hpid=topnews <comment><USER2> One of the reasons why highways and thruways are relatively safe is because of an enforced social contract (e.g. if you speed, you may get ticketed and if you drive erratically, you may put your life and other people's lives in danger)

With software, there is no such powerful peer contract. Software is not yet as good at self-healing (e.g. braking suddenly) if something unexpected happens. How do you handle a system exception safely and robustly at 65mph?

Automated cars are a pipe dream. Automated auto-pilot for cars on highways (e.g. automated platoons of cars moving in lock-step until they reach their exit) a.k.a Intelligent Transportation Systems (ITS) will be persistently hobbled in adoption because failure of the interface between humans and machines is dangerous at highway speeds. Recent ITS research has focused on trying to academically prove MITM attacks cannot work for certain ITS systems. Also, most people like freedom to drive whenever, whereever they want.

<comment><USER3> Highways are "relatively" safe? Relative to juggling chainsaws, maybe. After disease, cars are the leading cause of death in just about any country wealthy enough to have cars.

Drivers need all the help they can get from automation, even if it backfires now and then. The fact that any idiot who can spell his own name is allowed to hurtle through crowded streets with a two ton killing machine and no failsafes of any kind is clearly absurd.

<comment><USER4> _After disease, cars are the leading cause of death in just about any country wealthy enough to have cars_

No, they're far down the list. Less than 2% of all deaths are from auto accidents, fewer than influenza and pneumonia and 20x less than cardiovascular diseases.

<http://www.the-eggman.com/writings/death_stats.html>

<comment><USER5> Everything above auto-accidents on your list is a disease, so technically he's right =P

<comment><USER4> Oops, let me rephrase.

While car accidents are the leading non-accident way to die, you're 45x more likely to die from a disease.

</comment></comment></comment></comment></comment><comment><USER6> The metro crash may also exemplify an ATO system with a single point of failure, or poor maintenance, or poor training, or many other things. I am disappointed that no articles I've read about this crash have discussed the actual systems beyond them containing track circuits.

</comment><comment><USER7> So does the Air France crash. Speaking of which -- could GPS be used as yet another backup device for airspeed? It might have high latency, but it would be better than nothing.

<comment><USER8> I think the intentional lack of resolution in civilian GPS is in part because it is not intended to be an air navigation back-up system.

<comment><USER9> I was under the impression that the "degraded civilian" properties of GPS have been disabled for some years now.

<comment><USER10> I believe that IFR-certified GPS systems have the added capability of factoring Differential GPS. This is an additional GPS beacon (aside from the satellites) originating from the airport you're landing at, which have a location that's very accurately known.

High-price civilian GPS receivers are capable of this -- except you rarely have access to such a beacon. I mean, the restaurant I'm going to eat at isn't going to provide my little TomTom with a differential signal. With aviation, it's important enough that high-traffic airports provide the DGPS beacons.

<comment><USER11> This isn't true. IFR certified GPS units generally don't have Differential receivers. The main reason for this as far as I can tell is integrity. To be IFR certified, the receiver has to be able to tell when a satellite is giving bad data. In the older units, this was done with RAIM, which basically compares what is coming in from all of the satellites, and determines if all of the satellites are providing positioning that is relatively consistent. DGPS is a relatively simple system, and there's no way to check the DGPS signal for integrity. Without the ability to check for integrity, the additional accuracy is useless, as the design of instrument approaches is based on worst-case scenarios.

Now newer IFR certified units do have WAAS, which is similar to DGPS, except the signal is transmitted from a satellite, and is based on measurements from a couple dozen ground stations, the correction interpolated in the unit.

There has been a proposal to implement a system called LAAS for a number of years, which would be like DGPS, but would have the integrity checks that are required for aviation. However, it never really got off the ground.

As it stands, with WAAS, you can be guided to 200 feet above the runway, but this is not as good as the old analog radio ILS, which, if setup in a sophisticated way, can take a plane all the way to the surface.

</comment></comment></comment></comment></comment><comment><USER12> On the topic of "The better you make the automation, the more difficult it is to guard against these catastrophic failures in the future, because the automation becomes more and more powerful, and you rely on it more and more." it's instructive to read the last story of Asimov's "I, Robot" called the "Evitable Conflict" in which the machines lead the Earth's progress.

</comment><comment><USER13> This touches a lot on why the UI of your application is crucial.</comment>


Major Mobile US Networks Pass 50% IPv6 Threshold for IPv6-Enabled Hosts - <AUTHOR> http://www.worldipv6launch.org/major-mobile-us-networks-pass-50-ipv6-threshold/ <comment><USER3> Unless I'm misreading the confusingly-worded press announcement, this is 50% of traffic _to IPv6-enabled hosts_. Big difference.

<comment><USER4> IPv6 enabled hosts include Google and Facebook, so I'd guess that's a lot of traffic.

<comment><USER5> and netflix

<comment><USER6> My understanding was that Netflix was 100% AWS, and AWS' implementation of IPv6 was very limited and pretty much to the ELB only.

<comment><USER7> But other parts of AWS are often not public facing anyway.

</comment></comment></comment></comment></comment><comment><USER8> Don't think their numbers are right.

I manage 3 different sites with AAAA and A records.

site 1: tech site: 12% of the traffic is via IPv6

site 2: mixed/funny site: 7% is IPv6

site 3: company site: 9% is IPv6

I asked around a few friends and all of them with IPv6-enabled sites have around 5-15% of their traffic via IPv6.

Even Google sees 14%:

[https://www.google.com/intl/en/ipv6/statistics.html](https://www.google.com/intl/en/ipv6/statistics.html)

Can't believe this 50% number.

<comment><USER9> Those are world-wide numbers. Google reports 30% for the US: [https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...](https://www.google.com/intl/en/ipv6/statistics.html#tab=per- country-ipv6-adoption&tab=per-country-ipv6-adoption).

<comment><USER10> Yes, it's quite different in different countries.

My web server gets only 3,9% IPv6 traffic (based on counting unique IPs). Quite OK given that none of the major ISPs in my country offer IPv6 (neither on broadband or on mobile). Even for businesses it can be hard to get native IPv6 here.

</comment></comment></comment><comment><USER11> Unfortunately, amazingly, Android still does not support DHCPv6 so that you can take advantage of it. [http://www.techrepublic.com/article/androids-lack- of-dhcpv6-...](http://www.techrepublic.com/article/androids-lack-of- dhcpv6-support-poses-security-and-ipv6-deployment-issues/)

<comment><USER12> is this even an issue? dnsmasq(which most routers use) for example supports both.

<comment><USER11> Yes, it's an issue. My router cannot assign an IPv6 address to my phone if my phone can't ask for one.

<comment><USER13> If you really want IPv6 to work, enable SLAAC.

<comment><USER14> How are you getting DNS configuration (server + search domain) via SLAAC?

<comment><AUTHOR> With the RDNSS + DNSSL options for Router Advertisement (RFC standard since 2010), described here:

[https://tools.ietf.org/html/rfc6106#section-5](https://tools.ietf.org/html/rfc6106#section-5)

If you know a RA implementation that does not support this, please tell.

<comment><USER15> Or IPv4 DHCP, if you're not IPv6-only.

<comment><AUTHOR> You might not want to rely on a soon to be declared historic protocol for essential network configuration...

[https://tools.ietf.org/html/draft-howard- sunset4-v4historic-...](https://tools.ietf.org/html/draft-howard- sunset4-v4historic-00)

(This draft will probably expire, but shots are fired)

Edit: Here is a PDF that describes what deprecating IPv4 means

[http://ipv6.sa/wp- content/uploads/2016/04/IPv4_historic.pdf](http://ipv6.sa/wp- content/uploads/2016/04/IPv4_historic.pdf)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> So if I grab a SIM card from T-Mobile or AT&T and put it in my iPhone, will I actually get an IPv6 address? What about Verizon and Sprint? This is actually a valid use case for me as a way to access stuff at home while I am remote.

<comment><AUTHOR> Yes. But since too many sites still are only reachable via IPv4, you either get also an IPv4 address (dual stack) or you get connectivity via NAT64/DNS64. The latter case means your phone cannot be reached from the outside via IPv4 (this is rarely needed on a phone, except when tethering a laptop, maybe).

<comment><USER16> I am well aware of all that. I have been deploying IPv6 sites for a while now. I was more curious if there was any movement towards mobile devices getting IPv6. I am stuck with AT&T for a month longer or so and so I was wondering which carries actually support what I need. Last I checked AT&T did not, but that was over a year ago.

<comment><USER17> I have seen IPv6 addresses allocated to some ATT UEs. Not sure what was the percentage. Go here from the handset and check again? [http://test- ipv6.com](http://test-ipv6.com)

</comment></comment></comment></comment><comment><USER18> Too bad AWS, Azure and Google Cloud have patchy to zero IPv6 support.

<comment><USER19> I have a ipv6 only vlan/SSID at home, pretty much nothing works outside of ipv6.google.com without nat64/dns64.

It actually seems like its getting worse since world ipv6 day. www.bing.com literally turned it on for one day, then turned it off. Smaller sites seem to have left it on, but then forgotten that fact and over time more and more of them seem to have fallen offline/etc.

Then there are all the 1/2 ass implementations. My router is ipv6 enabled (edgeOS), but that means you get a GUI for configuring/viewing ipv4, and a command line for ipv6. My ISP has a 1 IP rule, even though they claim dual stack support, I can get either IPV6 or IPV4, not both simultaneously (even though the ipv6 is a block of IPs). Ugh...

<comment><USER20> It's definitely getting worse.

Internode are one of the only residential ISPs in Australia offering IPv6. They got bought by iiNet who still haven't deployed IPv6, who then got bought by TPG who are far more likely to put their entire customer base behind a single IP/CGNAT.

</comment></comment></comment><comment><USER21> 50% of all traffic to the dual stack hosts are going via IPv6. That's expected as most dual stack clients favour IPv6 over IPv4.

</comment><comment><USER22> Why are wireline providers still lagging with supporting it?

<comment><USER23> Because lack of demand and because v4 NAT still works.

Other reasons may vary from company to company. Sometimes, because first experiments with v6 were failures (users reported connectivity issues - <USER2> systems weren't working well, but it's ISP who gets the blame). And sometimes because proper v6 deployment takes a significant effort even if a company's lucky that the existing software was written with some v6 support in mind.

Most users don't even know what "IP address" actually is (they know the words and, in best case, that it's some numbers), not that it has "versions" or anything.

I believe mobile carriers need v6, as they have way too many always-connected devices on the network. Cable companies have more breathing space in this regard.

Source: used to work in a small(er) FTTH ISP company, and still keep in touch with them on some occasions.

<comment><USER22> _> Because lack of demand and because v4 NAT still works._

In a sense it's catch 22. To increase demand, ISPs should support IPv6. Otherwise everyone is forced to support IPv4 for their sites and services, and why would users demand ISPs to support IPv6 if sites and services work anyway?...

The problem is, NAT doesn't work. I.e. it kind of works, but it's a huge pain and cost to support for anyone who has to deal with it (from development standpoint). In essence, it's a monstrosity which only magnifies the problem by delaying the global switch.

So essentially in order to solve this, everyone should be putting an effort into enabling IPv6, and if someone waits for others to demand it, they are harming the whole transition.

</comment></comment></comment><comment><USER24> So is it the Year of IPv6 yet?

I've been hearing about this going mainstream for 13 years. I've been setting up servers to be dual homed with both IPv4 and IPv6 for years but so many people/companies don't even bother adding the IPv6 addresses as AAAA records in their DNS even when the servers support it.

But it's here. Exciting!</comment>


Reverse Engineering Snapchat: Obfuscation Techniques - <AUTHOR> https://hot3eed.github.io/snap_part1_obfuscations.html <comment><USER2> I'm surprised that no one has mentioned how this is actually accomplished. The answer is: largely automatically, at the compiler level.

Snapchat acquired Obfuscator-LLVM and the people behind it in 2017, which was actually partially open source for a period of time. It is a compiler backend for LLVM that obfuscates your code for you. You can read a bit about some of the techniques used on their old wiki:

[https://github.com/obfuscator- llvm/obfuscator/wiki/Features](https://github.com/obfuscator- llvm/obfuscator/wiki/Features) (outdated)

[https://www.bloomberg.com/news/articles/2017-07-21/snap- hire...](https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss- team-behind-software-protection-startup)

<comment><USER3> Funny thing about things like that is that you can likely write tools to automatically deobfuscate, if you know the mechanisms. Of course, this takes time and effort, and is beyond most spammers' capabilities.

<comment><AUTHOR> I'm gonna write about this in pt. 2. Basically you can use symbolic execution to recover the CFG[1] (using something like miasm), you can eliminate dead code, restore dynamic lib calls with an emulation, and whatever else. But the point is that it would take an incredible amount of work and co-operation between tools, and then you wouldn't have even begun understanding anything about the binary, which is a whole another story. Now there's a kind of a little shortcut to all of this, which when combined with a couple of tools, you'd be able to make sense of things in this binary, which I'm gonna reveal in my next post.

[1]: [https://blog.quarkslab.com/deobfuscation-recovering-an- ollvm...](https://blog.quarkslab.com/deobfuscation-recovering-an-ollvm- protected-program.html)

<comment><USER4> awesome write up, really engaging! I enjoy the cliff hanger at the last line... "one strange trick"....

<comment><AUTHOR> "Evan Spiegel Hates this Trick!"

</comment></comment></comment></comment></comment><comment> just-ok This is an awesome write-up; I'm shocked at the level of effort that went into Snap's obfuscation process. It implies that are entire teams of engineers out there whose sole job it is to play cat&mouse with reverse engineers and nothing more. Another comment mentioned that this effort is outsourced, so not only are there teams, but entire companies dedicated to this!

What a blast that must be... though the immense amount of [invested|wasted] (take your pick depending on cynicism) effort spent on this game makes me a little sad. All of these brilliant minds just... cosplaying Sisyphus?

<comment><USER5> >What a blast that must be... though the immense amount of [invested|wasted] (take your pick depending on cynicism) effort spent on this game makes me a little sad. All of these brilliant minds just... cosplaying Sisyphus?

And we wonder why such a high % of tech workers have a deep discontent & are desperately searching for meaning.

<comment><USER6> I would find that a very fulfilling and meaningful project, personally. I'd actually consider it way more fulfilling than working on the core product, which likely mostly involves trying to think of and implement clever ways to expose users to ads and sponsored content, and otherwise try to directly and indirectly monetize users.

Here, the goal is to prevent phishers, fraudsters, scammers, spammers, catfish, impersonators, malware spreaders, etc. from running amok in a somewhat unprecedented way by tricking users en masse into thinking they're really receiving photos/videos in real-time, using automated tooling. My understanding is this heavy degree of obfuscation (combined with other anti- tampering tactics) has gone a very long way to mitigate a huge amount of abuse.

From talking to people who've tried to bypass these mechanisms to do unauthorized and potentially risky things (like send things from a custom client in a way that could allow for mass automation), they describe this as an essentially intractable hurdle from their perspective. Of course, it isn't in actuality, but it is for most people when compared to lots of other social media apps, and I expect Snap to change things around not long after OP releases part 2. Cat-and-mouse never ends.

<comment><USER7> > Here, the goal is to prevent phishers, fraudsters, scammers, spammers, > catfish, impersonators, malware spreaders, etc. from running amok in a > somewhat unprecedented way by tricking users en masse into thinking they're > really receiving photos/videos in real-time, using automated tooling. My > understanding is this heavy degree of obfuscation (combined with other anti- > tampering tactics) has gone a very long way to mitigate a huge amount of > abuse.

Which is STILL in the service of trying to expose users to ads and sponsored content.

I find it sad that people in our industry are so easily distracted by the technical challenge du jour without looking at the bigger picture of what their work is in service of, which was OP's point.

<comment><USER8> Are you saying you shouldn't help an app that exposes users to ads prevent people from running automated fishing-for-nudes campaigns that have been used in the past to bully teenagers into suicide?

<comment><USER9> No, not this way. If my goal is really to push content to users I'd get a set of account and automate the sending/scraping using a device emulator. Ultimately their efforts are better spent elsewhere if this is the actual goal. In reality the goal is to attempt to keep people from reverse engineering the api so they can create a custom, ad free, client.

</comment></comment></comment></comment></comment></comment><comment> jor-el Some I see are surprised to see the level of obfuscation used in the application. Many pointed, many ingredients for the obfuscation used in the app are off-the-shelf and few of them can be said to be well known in the industry, but still there is a cost in integrating them into a product. Obfuscation is notorious in breaking things which should work normally (normal compilation process) and as a own goal making it hard to debug as well. Integrating, testing, debugging and difficulty in debugging production crash logs is a considerable cost.

That said, obfuscation is increasingly being used in mobile applications now. Check your banking application or some government applications, you will find obfuscation being used. With mobile applications getting richer and lot of code executing on the client side, makes it compelling case to secure applications by using obfuscation (as a defense-in-depth approach).

Open standards like OWASP MSTG [1] MSTG-RESILIENCE-9 recommend such approach.

      Obfuscation is applied to programmatic defenses, which in turn impede de-obfuscation via dynamic analysis.

[1] [https://github.com/OWASP/owasp- masvs/blob/master/Document/0x...](https://github.com/OWASP/owasp- masvs/blob/master/Document/0x15-V8-Resiliency_Against_Reverse_Engineering_Requirements.md)

<comment><USER10> I think that it is due to the copy cats that keep stealing apps and repacking them.

Most Android developers lack native coding experience, so after failing attempts to protect their applications with the DEX bytecodes obfuscator, they think that recoding parts of the application with the NDK will save them.

However as this article shows, and most here know, they shortly learn that against good attackers, the only benefit from using native code directly is it takes a little longer to decipher what the application does.

So then one turns to solutions like what you are describing.

<comment><USER11> > they think that recoding parts of the application with the NDK will save > them.

Yeah like that one app I reversed a while ago that generated the API key in a native library. I was able to get the key by building my own app around their library and calling the function that returns the key. Didn't even have to disassemble the thing.

</comment></comment></comment><comment><USER12> Snapchat acquired Strong Codes in 2017. Before the acquisition they used Strong Codes compiler for obfuscation.

[https://www.bloomberg.com/news/articles/2017-07-21/snap- hire...](https://www.bloomberg.com/news/articles/2017-07-21/snap-hires-swiss- team-behind-software-protection-startup)

</comment><comment><USER13> This is brilliant work, I'm hoping in part II we get to see it working against the API.

I reverse engineered this in a production environment. It took approximately 7 months to build a scalable solution.

The investigation on how to create the x-snapchat-client-auth token is brilliant. One day I hope to do a talk on what my old team did to circumvent it.

There's a painful gotcha on the homestretch for this token: You may be creating the token, but it's not obvious what you're supposed to be using the method to sign.

What do they use it for? As far as I could tell, it's so they can verify requests at the edge nodes of their network. When you provide a bad x-snapchat-client-auth, you get a near-instant 403.

<comment><USER14> I think edge node is just checking if x-snapchat-client-auth valid, without checking if x-snapchat-client-auth is valid for this request. The second check is probably done at deeper level.

</comment></comment><comment><USER15> I remember back in 2013(?) I went to a collegiate hackathon in Santa Monica. Evan Spiegel showed up to walk the floor and someone showed him how they had sniffed the API and did something interesting with it (forget the particulars now, getting old). If I recall correctly, Evan offered the kid a job on the spot but the kid turned him down.

They've come a long way since then!

<comment><USER16> Was this perhaps LA Hacks [0] in 2014, or Hacktech [1]? Evan Spiegel attended LA Hacks, but I had someone who was attending Hacktech email me for help with the Snapchat API for their project. (I was part of Gibson Security, and published some early Snapchat API research [2] online in 2013)

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

[1] [https://medium.com/hacktech-2014/everyones-watching- hacktech...](https://medium.com/hacktech-2014/everyones-watching- hacktech-5b58c3859747)

[2] [https://gibsonsec.org/snapchat/fulldisclosure/](https://gibsonsec.org/snapchat/fulldisclosure/)

<comment><USER15> Almost certainly HackTECH; it was held in a mall in Santa Monica right by the beach. I'm almost sure Evan came but it wasn't to give a formal talk, but rather take a pretty low-key stroll-through. Maybe my mind is playing tricks on me. I did attend LA Hacks as well but I think it was in 2015, it was in Pauley Pavilion for the first time.

Your research looks fascinating and sounds similar to what I remember of the hack. Might be the same person we're talking about. Small world!

<comment><USER16> I did some more searching, and I think it was Hacktech then. According to [0], Evan dropped by because of the project by Ash Bhat and Ankit Ranjan, apparently some of the organisers called him since he lived nearby. Seems you were right.

[0] [http://appstorechronicle.com/2014/01/exclusive-snapchat- hack...](http://appstorechronicle.com/2014/01/exclusive-snapchat-hackers- friend-4-million-users-and-show-work-ceo-snapchat.html)

</comment></comment></comment></comment><comment><USER17> Snapchat is notoriously difficult to automate/spam.

The goal is to get the X-Snapchat token. The most elegant solution is to find the secret in the binary and reverse the algorithm to generate tokens. Wouldn't it be easier to MITM the endpoint; set up a dummy server (which collects tokens) in front of a proxy that spoofs the DNS and TLS certs (may be easier on rooted Android than iOS).

In my last attempt I gave up and went for dumb UI automation, but it would be cool (and worth good money) to exploit the private API.

<comment><USER18> Certificate pinning spoils that, no spoofing of certs with pinning.

Cert (or hash of) delivered with app. If server cert doesn't match expected value coded into app, someone is messing with something, terminate connection.

<comment><USER17> Yes that complicates things. But if you can find the cert in the binary's data section, maybe you can patch it with your own.

<comment><USER13> Assuming this is for Android, the APK would no longer be signed and would cause all login attempts to fail.

Have a read about "SafetyNet Attestion API" for Android.

<comment><USER19> You could patch Android and run it in an emulator. Or patch Snap not to care. Not super familiar, but there should be a way. Client side security can only do so much.

<comment><USER20> You can't patch Snap to not care because the safetynet process is (roughly) like that: The App asks the Play libraries whether the phone is okay. This is verified (in part) on the Google servers, so the Snap servers can ask Google whether a call came from a non-tampered phone. The client can't do anything about it, except tricking google into believing the phone is not tampered with. Which is notoriously hard, because nobody knows how the process really works.

<comment><USER21> In my experience, SafeteyNet bypass on rooted devices has been a solved problem for a long time through Magisk Hide.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> Well at this point, you might as well run the binary in a Mach-O ARM emulator since Snap has seriously cranked up the reversing difficulty to level 10,000.

I suggest anyone looking at this would need to use Corellium such that Snap has made it hard for _almost_ anyone to get their private API.

<comment><AUTHOR> Your only hope for emulating the whole thing would be Corellium, really. Too many real-device-dependencies.

<comment><USER23> This was a few years back but I had token generation working with something much simpler than Corellium using [https://github.com/unicorn- engine/unicorn](https://github.com/unicorn-engine/unicorn) emulator [You will need to set up CommPage, handle system and mach traps, load dyld, etc]. They've probably added more security since then but back when I looked at it some of the data that was encrypted in the token off the top of my head was:

\- Request Path \- Timestamp \- Snapchat Binary Size \- Bit Flags for various hack checks such as jailbreak, checks for various tweaks, etc. \- Device Type \- iOS Version \- A pair of counters, I believe these were being used to detect real devices being used as signature proxies. \- A unique device ID generated at startup

I can't remember which one of the tokens this was for. There is a X-Snapchat- Client-Token used at login if I remember correctly and X-Snapchat-Client-Auth- Token which is used for every request.

I never ended up using it for anything but it was a lot of fun getting token generation working through emulation. I'm not sure if I was actually able to bypass all their checks or if it would have been detected had I actually tried to deploy it for something in production.

</comment></comment></comment><comment><USER24> If you dig very deep, you can also find an offer to come work at Snapchat. Most will never find it.

<comment><USER25> Those who do have the skill to find it probably have better places to work for than a barely profitable company whose only revenue stream is to push trashy clickbait.

<comment><USER24> Barely profitable companies regularly pay big salaries for the right people, it's why they're barely profitable.

</comment></comment></comment><comment><USER26> I'm curious, can anyone recommend any techniques (or companies providing solutions) for attempting something similar with javascript in a browser calling an API? Obviously it's much more difficult to obfuscate an algorithm for generating a client token in JS than it would be in assembly, but I'm just curious if anyone has tried any form of "lock down my API so it's only callable from the web front end I provide" obfuscation.

<comment><USER27> You can study the Instagram or TikTok web versions for inspiration.

Both use some wacky methods for request signing that include encrypted code, obfuscated control flow, hashing the browser environment, ...

Assembly obviously allows for much more powerful obfuscation than Javascript. Webassembly is somewhere inbetween, but a viable path since it is pretty universally supported by now.

Networks requests can be inspected trivially in the browser though, which makes things a lot easier.

<comment><USER28> Other methods out there to hide network requests in-browser.

<comment><USER27> Sure, you could do all kinds of things. Using GET requests with a encrypted payload in the URL, websockets with some wacky custom protocol on top, WebRTC shenanigans, ...

I haven't seen anything like that in the wild, though.

</comment></comment></comment></comment><comment><USER29> > _To make your life even more miserable, Snap ocassionally deprives you of > recognizing some basic standard lib functions ... You won't be very happy > after spending a day or two reversing a function to find it's memmove in the > end._

That sounds particularly devious.

</comment><comment><USER30> Philosophically I never gave much thought to securing app client code.

Why not just track usage stats and ban clearly fake/high throughput users?

<comment><USER31> Because Snapchat is ultimately an application designed to trade in porn of amateurs including (and perhaps especially) teenagers.

They have a vested interest in playing dumb to that fact. They can't really do so if the content escapes out into the wild and shows up in congressional hearings, lawsuits, FBI investigations, DOJ reports, etc.

<comment><USER32> I think you wildly misunderstand how many people (teenagers included) who use Snapchat for PG-rated things exclusively. The end-to-end encryption (of snaps) and "disappearing" nature makes it work well for anything sensitive, but porn is certainly not the only thing people use it for.

Also, any party to a conversation can use the report button to send the unencrypted message to Snap for review. They employ actual content moderators as well, who have made reports to federal law enforcement before.

<comment><USER31> Sounds like a bit of lipstick on a billion dollar pig. I'm sure we all remember their early days, their marketing material was straight out of any drunken frat boy's phone.

I mean, pornstars say 90% of pornstars are selling content on Snapchat.

[https://www.wired.co.uk/article/premium-snapchat-adult- model...](https://www.wired.co.uk/article/premium-snapchat-adult-models)

<comment><USER32> I think that's true for the beginning, and I'm not disputing your statistic, but as a percentage of the total userbase today, people using it for non-porn- related purposes are the vast majority. Even if nearly 90% of porn stars use it, nowhere near 90% of Snapchat's users produce or consume adult content on the platform.

Do you use Snapchat? Do you have friends who do? It's the de facto communication standard for teenagers because of Quick Add and the gamified nature, not porn.

<comment><USER31> No, I have no purpose for it, but I'm in my 40s. Twitter and Facebook are the only social media platforms I use.

To say snapchat has no basis in trading porn is to say that pornhub could relaunch itself tomorrow and say "oh sorry we're just a youtube knockoff now, we're not in the adult industry."

Well, it would still say pornhub in the URL, wouldn't it. And it would still be a site whose entire userbase was built on trading porn. That's what Snapchat built and used to grow its userbase, so trying to re-image themselves after getting the money is dubious at best.

</comment></comment></comment></comment></comment></comment><comment><USER33> This is some pretty heavy-duty obfuscation. What is the business case for this amount of work towards preventing reverse-engineering? Decent rate limiting should be much more effective than making such a herculean effort to obfuscate one's API.

Edit: another comment mentions that snap chat uses an existing solution, which makes more sense than the expense of developing this sort of obfuscation in- house: [https://news.ycombinator.com/item?id=23558784](https://news.ycombinator.com/item?id=23558784)

<comment><USER34> Specifically, Snapchat wants to stop "tweaks" and alternate frontends that allow for bypassing of Snapchat's self destruction controls.

This is especially important given that Snapchat is widely used to trade amateur underaged pornography.

</comment></comment><comment><USER35> Seems like hooking the UI layer and intercepting data on the wire would be a much simpler approach. I wouldn't even try to circumvent the UI flow or animations. The more 'user-like' the activity, the more difficult it is to distinguish automation from human traffic. This doesn't scale as well well as many would like, but it can work. You could probably bundle something like this up and resell it as a grey-market API.

There may be some money in standing up a datacenter that is filled almost exclusively with smartphones.

</comment><comment><USER36> How many of these tricks are off the shelf techniques? Seems like a tremendous effort.

<comment><AUTHOR> OP here. About half are off the shelf. Joint functions, the breakpoint infinite loop, in-house memmove, the overflowing thing, those I haven't read about anywhere before.

<comment><USER37> For the overflow, Jagex with RuneScape did it in Java. They also did stupid Object arrays 7 or so levels deep, doing casts on casts in between. The bytecode itself made the actual runtime slow to a crawl (anywhere from 5 to 10x slowdown.) This was circa 2014.

<comment><AUTHOR> That's interesting to know

</comment></comment></comment></comment><comment><USER38> Do tiktok next, their obfuscation techniques are quite interesting. :)

<comment><AUTHOR> Why not ;)

</comment></comment><comment><USER14> Best value of this kind of obfuscation is they usually rely on a random seed, and every time you obfuscate you have different results. So once you update the app (and change hash function), for new version, spammer need to the all reversing once again.

<comment><AUTHOR> Not all of it, really ;)

</comment></comment><comment><USER39> One thing I'm curious about is what they do to try to stop you from just ripping out the obfuscated token generation library and setting up a harness to run the whole thing in [https://www.unicorn- engine.org/](https://www.unicorn-engine.org/) or something. Like presumably they don't compile their whole app with obfuscation and it's just some library that's linked in with some kind of stable-ish API contract with the rest of the app. I wouldn't be surprised if they do interesting things to try and stop you from ripping it out and it'd be cool to learn what those are.

<comment><USER8> Why wouldn't they obfuscate the whole app?

<comment><AUTHOR> That'd be a noticeable performance hit I'd say.

</comment></comment></comment><comment><USER40> All these to make Snapchat not being recorded. Well, it's a mouse and cat game and currently the cat is winning, as in using Memu on my PC allows me to record everything happening there, your crush nudes and dances included.

</comment><comment><USER41> This sort of thing has been prevalent in the game world for decades.

I once had the chance to work on a project disassembling casino machines, and they had similar protection appropriate for the technology of the time

</comment><comment><USER42> There are already alternative front-ends for YouTube, Facebook, and Reddit. I'd love to see one for Snapchat and Instagram, although it looks like one for Snapchat would be incredibly difficult.

<comment><USER43> Most usable alternative front-ends for such services are usually just parse web API or even plain html in case of YouTube. Snapchat don't have any web app so parsing it is tricky and Instagram provide only limited set of features on the web.

</comment></comment><comment><USER44> How would one go about understanding the content of this write-up? Even after the first paragraph it begins to go completely over my head.

<comment><AUTHOR> You need some assembly background, then OWASP's guide[1], has all basics.

[1]: [https://github.com/OWASP/owasp-mstg](https://github.com/OWASP/owasp- mstg)

<comment><USER44> Thank you very much.

</comment></comment></comment><comment><USER45> I would love to be able to make a bot for the snapchat group my friends and I have. We already have a blast using it now. A bot that could randomly do things that we could all interact with would be hilarious. Sadly I don't think this functionality will be introduced. So it will be cool to maybe slap something together before all of this gets fixed.

</comment><comment><USER46> Interesting read! I'd love to read the next post, but at least Miniflux can't find any feed.

3eed, would you be open to adding an RSS feed?

<comment><AUTHOR> Sure! I'll consider doing this before the next post

<comment><USER46> Thanks!

</comment></comment></comment><comment><USER47> How does one go about learning reverse engineering? Is it mostly by practicing? Are there any good up-to-date resources?

I remember taking a reverse engineering course in the university where the professor didn't even bother to explain the basics, it was like black magic and left me frustrated, but I still feel amazed when I read blog posts like these.

<comment><AUTHOR> [https://news.ycombinator.com/item?id=23563556](https://news.ycombinator.com/item?id=23563556)

</comment></comment><comment><USER48> I was wondering if there are any steps a developer of a small app can take to add such a header and lock down the API so it only answers to said header. This level of obfuscation doesn't seem doable for smaller shops. Is there something simpler, that is "good enough"?

<comment><AUTHOR> Security is a continuum, how much resource you can put into fending off prying eyes depends on how valuable your assets are and so how many prying eyes are targeting you. But as a start OLLVM is open source and not bad at all.

</comment></comment><comment><USER49> I have been advised by researchers in the field that it takes about a day with an optimizing compiler to de-obfuscate most any piece of commercial software of this size, with a good team. With a less than great team, perhaps about a week. Is that true?

<comment><AUTHOR> Definitely not true.

</comment></comment><comment><USER50> CORRECT LINK: [https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.ht...](https://hot3eed.github.io/2020/06/18/snap_p1_obfuscations.html)

</comment><comment><USER51> Wow, that seems really messy. If you're just after the API key or whatever, wouldn't reversing the Android app be simpler? As far as I know, you can't do all these low-level tricks on the Java platform.

<comment><USER52> Android was way easier until Google started helping out and introduced SafetyNet attestation. I think it was orginally coded for Google Wallet/Pay but Snapchat were definitely using it from early on. Pokemon Go use it as well.

Apple have no such system as far as I can know, and if they do, don't share it with 3rd party developers.

</comment></comment><comment><USER53> > In Mach-O binaries, functions whose pointers are in the __mod_init_funcs run > before main.

Remember that obfuscation makes your code run slower. This specific one is part of the reason why the dyld team probably hates you.

<comment><USER54> The performance impact is not as much as you'd think, speaking from C/C++ land. I had a secured video player that was using these techniques, and even with the dial turned all the way up, it was costing 1-2% CPU and no human- detectable latency

</comment></comment><comment><USER55> to answer everyone asking 'why do they do it????' its because of spam, that simple. they dont want:

a) outbound bots that send messages to users created in bulk messaging millions of users. b) inbound chatbots that answer messages c) when they had snapcash, they didnt want bots generated collecting cash.

spam is a multi million dollar industry.

@3eed i guess it's not considered obfuscation but you gotta pass the correct version # or you won't be able to connect either, old versions are immediately obsolete.

<comment><USER55> oh whoops forgot they also dont want scripts following users then logging all their private pics/posts without flagging it as beeing screenshotted which defeats the purpose of the app.

</comment></comment><comment><USER56> This is what the top 1% of MIT grads work on. Obfuscating IP for a user data company.

It's clever, but man... I have to believe these talented folks were destined for something greater.

</comment><comment><USER57> Are any of these obfuscation techniques possible on the web? My guess is no, but just curious.

</comment><comment><USER58> Things were definitely much simpler a couple years ago.

<comment><USER59> I'm actually a bit surprised it's taken as long as it has for mobile obfuscation to catch up. Both on the Android bytecode and the iOS native code side there are obvious PC analogs in the form of .NET obfuscators for MSIL and packers and game DRM for native code. Of course, the Obj-C runtime throws a little wrench into things on iOS, making it a bit of a hybrid - but the approaches are still similar.

It's still an ultimately pointless cat and mouse game as long as an attacker can trace the hardware (and with full-platform emulation tools like Corellium, this capability is unlikely to go away soon), but still an amusing one to watch.

<comment><USER60> I've seen this for _years_ already - it might also be because of a bit of an app usage difference, where the people that typically do these writeups or browse HN don't install the shitware on the app stores that do these things, except for rare common cases like large communications platforms (Snap)

Many Asian mobile games run malware DRM like this - [https://www.wellbia.com/home/en/pages/xigncode3-for- android/](https://www.wellbia.com/home/en/pages/xigncode3-for-android/)

They are incredibly invasive and insecure, exfiltrate tons of PII (location, private IP, mac, ...) where possible unencrypted to bare IPs in various countries. This company in particular also has a PC-based anticheat rootkit that doesn't prevent cheating and allows the developer to "remote control the user", which is also an advertised feature.

</comment></comment></comment><comment><USER10> Very nice article. Great piece of work.

</comment><comment><USER61> Great write up! Thanks for posting!

</comment><comment><USER62> Will Apple approve an app with this level of Obfuscation in it's source? I thought they had to have the source itself?

<comment><USER53> No, they don't. You can provide them with symbol files for your application so they can symbolicate crashes on your behalf, but this isn't required. (Interestingly, there are teams at Apple that reverse engineer applications for compatibility reasons, and the occasional "someone got an obfuscated binary past app review and we need to know what it does".)

<comment><USER62> Huh, thanks. I thought they reviewed the source of all apps to make sure they aren't doing anything naughty.

<comment><USER3> That would be ridiculously expensive.

</comment></comment></comment></comment><comment><USER63> Doesn't Snapchat mainly rely upon the iOS or Android platform having some software that prevents screen shots if a 'no screen shots' flag is set? I always thought this was their core defense.

<comment><USER59> Their "core defense" for an end user is to notify the sender of a message if their post was screenshotted by using native screenshot detection/notification libraries provided by the OS, combined with heuristics to try to prevent them from beeing hooked and bypassed.

However, the binary level protection is only tangentially anti-screenshot insofar as it also blocks third-party 'scraper' apps. Fundamentally, it's about requiring use of the Snapchat app to access the Snapchat APIs, and as we know from the ongoing saga with other social networks like Twitter, this is ultimately about business control over posts (preventing spam-bots, scheduled clients, and so on) and at the end of the day, ad revenue.</comment></comment>


How to extract audio from a video - <AUTHOR> http://yaplc.blogspot.com/2008/10/how-extract-audio-from-video.html# <comment><USER2> To quote Ralphie, "A crummy commercial!" I'd like to think that "hacker news" would be something a little more complex than documenting 5 steps of clicking buttons.</comment>


Get a profile based on your real experience - <AUTHOR> https://www.masterbranch.com/

<comment><USER2> I'm the co-founder of Masterbranch.com. Thanks for sending out the link.

We would love to heard any feedback you guys have and also what do you expect from a site like Masterbranch.</comment>


Bloxes Brings Cardboard Tech To The Office - <AUTHOR> http://www.techcrunch.com/2008/03/07/bloxes-brings-cardboard-tech-to-the-office/ <comment> patrickg-zill 20 pieces of cardboard for $60? I can buy a CHAIR for $60 and have Staples deliver it.

</comment><comment><USER2> dude...too many little pieces. If you can make these things assemble themselves, then _that_ would be cool.

<comment><USER3> near as I can tell from the site, each block is made from exactly one piece of cardboard.</comment></comment>


Web 2.0 Company Name Generator (actually not bad) - <AUTHOR> http://www.lightsphere.com/dev/web20.html

<comment><USER2> And the source code is fun too:

<http://www.dotomator.com/web20.js>

</comment><comment><USER3> That's hilarious, thanks for the much-needed comic relief. :)

</comment><comment><USER4> most of the names i was getting were already taken

<comment><USER5> Yeah, I signed up for one of those sites where you pay them $50 to choose a name for you. Soon after, I discovered that those #$@#$ where just feeding me names from this! I refunded.

</comment></comment><comment><USER6> zazuk.com it is!</comment>


Show HN: Publishthis.email – Create a web page in seconds, by sending an email - <AUTHOR> http://www.publishthis.email/ <comment><USER2> Incredibly handy and awesome - especially when using it together with [IFTTT]([https://ifttt.com](https://ifttt.com))!

</comment><comment><USER3> Maybe add the ability to purchase a domain name somehow to monetize? But this would likely take away the email-only aspect.

<comment><USER4> I think this would be a nifty way to monetize

</comment></comment><comment><USER5> How are you dealing with email? I recently started looking at this and it was a bit more annoying than I hoped for. Currently it seems like I am settling down with Python + imaplib/email modules and a lot of stack overflow Q/A's.

</comment><comment><USER6> Very nice. I would love to read a list of use-cases, but I'm ok if they don't exist, because this is just a nice hack.

Reminds of [https://github.com/fiatjaf/questo.email](https://github.com/fiatjaf/questo.email)

<comment><USER7> Another creator here. We have no specific use cases, but the ideas floating around my head: 1) Leaking controversial conversations, whistleblowing, or simply sharing interesting emails. 2) Being one of the fastest ways to publish, could be a new blogging platform, especially for the older generation who is more comfortable with email. 3) Transparency for businesses/government through public archiving.

I would love to hear other ideas.

<comment><USER8> > 1) Leaking controversial conversations, whistleblowing, or simply sharing > interesting emails.

Hmmm if this is a goal you should support encryption.

Perhaps provide a public key and have an auto decryption mechanism with your private key.

</comment></comment></comment><comment><USER9> Very cool. I like the idea enough that I want to find a reason to use it, but none comes to mind immediately. The real problem, it seems, is not being able to get something on the web, but getting anyone to look at it.</comment>