Apple starts rejecting apps with "hot code push" features - <AUTHOR> https://forums.developer.apple.com/thread/73640 <comment><USER3> I'm Erez Rusovsky, the CEO of Rollout.io

Rollout's mission has always been, and will always be about helping developers create and deploy mobile apps quickly and safely. Our current product has been a life saver for hundreds of apps by allowing them to patch bugs in live apps.

We were surprised by Apple's actions today. From what we've been able to gather, they seem to be rejecting any app which utilizes a mechanism of live patching, not just apps using Rollout.

Rollout has always been compliant with Apple's guidelines as we've detailed in the past here: [https://rollout.io/blog/updating-apps-without-app- store/](https://rollout.io/blog/updating-apps-without-app-store/)

Our SDK is installed in hundreds of live apps and our customers have fixed thousands of live bugs in their apps.

We are contacting Apple in order to get further clarification on why Rollout doesn't fall under the clause that lets developers push JS to live apps as long as it does not modify the original features and functionality of the app.

I'll post updates as I have them.

Erez Rusovsky CEO Rollout.io

<comment><USER4> Oh man. You were surprised? Really? You blog sounds like the PR spin that came out of Aereo, a company that spent an inordinate amount of effort to stay within the absolute letter of a law. Predictably they got killed by lawsuits because judges aren't idiots and the law isn't inflexible to the point where the intent and context isn't considered. Your case is even worse because you engineered a solution to adhere to the letter of a EULA of a tightly controlled ecosystem run by a very capricious company.

I hate the app store review process and a lot of apple policies around the app store and I feel for you and I totally think there should be a less onerous update/review process ... but ... you clearly and blatantly circumvented a core policy, and what happened to you was absolutely predictable.

Get your money back from the lawyer that told you Apple wouldn't shut you down. You got bad advice.

<comment><USER5> > _Oh man. You were surprised? Really?_

Exactly!

Apple has always been adamant that they see _all_ code that goes onto devices. Live patching is so bloody obvious against their EULA.

<comment><USER6> What is "code"? Everybody who has programmed in LISP or Scheme knows that there is no essential distinction between code and data (only many programming languages make it a little hard to see that it is all the same). Thus Apple would have to see not only all code, but also all data that goes onto the devices. But this would imply that Apple disallows all apps that read data from a foreign (i.e. at least not Apple-controlled) server if one does not want to get into a self-contradiction.

<comment><USER7> Which is why you're not allowed to use a Lisp interpreter or use any method of evaluating data as code. In this model the only thing that data can do is change which code paths run, not what they do.

<comment><USER8> That characterization isn't enough to distinguish a Turing complete interpreter from something that trivially manipulates an input datum. An interpreter is just a program containing code paths, which are activated in response to the input (the interpreted code).

<comment><USER6> > That characterization isn't enough to distinguish a Turing complete > interpreter from something that trivially manipulates an input datum. An > interpreter is just a program containing code paths, which are activated in > response to the input (the interpreted code).

It is surprisingly simple to make an interpreter that is "accidentally" Turing complete (this IMHO so often happens by accident that I love to say that if an interpreter is not "obviously" more restricted than a Turing machine, it probably is Turing complete).

This is not just my opinion - there lots of pages in the internet of things that are "accidentally" Turing complete, for example:

[http://beza1e1.tuxen.de/articles/accidentally_turing_complet...](http://beza1e1.tuxen.de/articles/accidentally_turing_complete.html)

[https://www.gwern.net/Turing-complete](https://www.gwern.net/Turing-complete)

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> "Hi there -- I believe that title isn't quite accurate; Apple specifically is referring to behavior of a library called Rollout which lets people dynamically inject Objective-C/Swift. They are doing hot delivery of native, Objective-C code. It's really not about React Native nor Expo.

Expo (and the React Native library we use) doesn't do any of that. We also make sure we don't expose ways to dynamically execute native code such as the dlopen() function that Apple mentioned in that message. We also haven't received any messages from Apple about Expo, nor have we heard of any Expo developers receiving the same." \- Exponent Team

<comment><USER10> Hi, I work on Expo (YC S16) and also am a core contributor to React Native.

Apple's message reads to me that they're concerned about libraries like Rollout and JSPatch, which expose uncontrolled and direct access to native APIs (including private APIs) or enable dynamic loading of native code. Rollout and JSPatch are the only two libraries I've heard to be correlated with the warning.

React Native is different from those libraries because it doesn't expose uncontrolled access to native APIs at runtime. Instead, the developer writes native modules that define some functions the app can call from JavaScript, like setting a timer or playing a sound. This is the same strategy that "hybrid" apps that use a UIWebView/WKWebView have been using for many years. From a technical perspective, React Native is basically a hybrid app except that it calls into more UI APIs.

Technically it is possible for a WebView app or a React Native app also to contain code that exposes uncontrolled access to native APIs. This could happen unintentionally; someone using React Native might also use Rollout. But this isn't something specific to or systemic about React Native nor WebViews anyway.

One nice thing about Expo, which uses React Native, is that we don't expose uncontrolled or dynamic access to native APIs and take care of this issue for you if your project is written only in JS. We do a lot of React Native work and are really involved in the community and haven't heard of anyone using Expo or React Native alone having this issue.

<comment><USER11> This needs a little elaboration. Cached Javascript in any hybrid app is a security hole because that can be exposed through a jailbreak. Depending on how much of your business logic you've pushed into the JS layer to enable that "80% code sharing" that makes managers go all tingly you may be exposing all kinds of things - cached access tokens, API keys and whatnot - to anyone who wants to install your app and mine its secrets.

<comment><USER12> You as an end user jailbreaking your own phone is not a "security hole".

I'm not aware of any non-tethered jailbreak for iOS 10

<comment><USER13> I think he's talking about application wide (not user specific) "secrets" in the javascript layer.

<comment><USER11> Yes, I am. As for untethered jailbreaks, [http://pangu8.com/10.html](http://pangu8.com/10.html) mentions a few.

</comment></comment></comment></comment></comment></comment><comment><USER14> It seems that most people are overlooking one of the more significant points Apple have made here:

"Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app."

Source: [https://github.com/bang590/JSPatch/issues/746](https://github.com/bang590/JSPatch/issues/746)

<comment><USER15> I'm not buying the MITM argument in general. If remote code is downloaded via HTTPS, it could not be hijacked, at least not easily.

<comment><USER16> HTTPS is sufficient against MITM, until someone disables all verification to use their self-signed cert, or adds their poorly-secured "CA" cert to the allowed CA's for the download, or adds a weak cipher to the list. Do you trust every app developer to do those right (if they even use HTTPS!)[0], or would you rather trust Apple to get it right in the centralized system they designed for app updates for all apps?

I'm not even fond of Apple, but I'd rather trust them, and I'm glad they're protecting their users.

[0] Caveat: I don't know how likely/possible these are to occur on iOS. I assume a sufficiently motivated & misguided developer could do them within their own app's context.

<comment><USER15> You see, this whole thing:

"Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app."

Basically says "only we, Apple, can do HTTPS right, you can't, and even if you try you can easily be MiTMed". Which is I don't agree with.

What you say is correct, but it's not the argument I criticize. You point is that they don't trust developers to implement secure loading of code and don't have technical means to control it and can't or don't want to check it in the review. But it's completely different to "you could be easily hijacked if you're not Apple".

<comment><USER14> I'd trust Apple to do right more than I'd trust a small team at a startup trying to deliver features at breakneck speed. I really like the fact that Apple is looking out for its customers here.

</comment></comment></comment></comment></comment><comment><USER17> Seems like people have been aware of concerns about violating the TOS with these hot patch frameworks.

From April 2016

>>Rollout is aware of the concerns within the community that patching apps outside of the App Store could be a violation of Apple's review guidelines and practices. Rollout notes both on their FAQ site and in a longer blog post that their process is in compliance.

[https://www.fireeye.com/blog/threat- research/2016/04/rollout...](https://www.fireeye.com/blog/threat- research/2016/04/rollout_or_not_the.html)

<comment><USER18> A ton of games do this and it is incredibly annoying. I don't want to download an update, then have to download an update. I only wish the same restriction applied to my Android device.

<comment><USER19> Most likely most games are updating only game related data and graphics files. Very few games actually use internal scripting that would be needed to do code updates

<comment><USER20> The only app I've got that appears to actually update itself without going through the AppStore is the HSBC mobile banking app. I'd be interested in hearing the discussions going on between Apple and HSBC at the moment.

<comment><USER21> Judging by how sluggish and annoying the HSBC app is, I think it is a web app framed in a thin launcher from the app store.

I.e. it downloads a bunch of javascript/html/css and that executes within a UIWebView/WKWebView. Using caching and localStorage, you can construct such an app to not need to download everything on each launch.

The reason that's allowed is because everything executes within a sandboxed browser environment. No native code is downloaded.

<comment><USER22> > The reason that's allowed is because everything executes within a sandboxed > browser environment. No native code is downloaded.

That's the same thing Rollout does. In fact, iOS apps _can 't_ download and run native code. The OS won't let you mark pages as executable unless they're appropriately signed, and only Apple has those keys.

<comment><USER23> If they're using JSC, then they can definitely download JS and execute native methods. They could subclass any UIKit object and make it conform to JSExport. Done, now they're "running native code."

<comment><USER22> Sure, and an app displaying a web page using WebView can provide hooks that allow doing that sort of thing too. Neither one is downloading native code.

<comment><USER23> Only UIWebView, which is going away soon.

But surely you can see the difference between executing limited actions inside a web view, and making available any native method to a web view.

<comment><USER22> WKWebView allows the app to execute arbitrary JS within the loaded page, and intercept URL loads and other actions made by JS code. That's all you need to build a bridge.

I don't see any fundamental difference here. Both (UI|WK)WebView and JSC allow bridging. Neither one grants full access to JS code automatically, the programmer has to put some effort into it. And even if there is some important difference, _neither one is native code_ which is what I was disputing above.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> From [https://rollout.io/how-it-works/](https://rollout.io/how-it-works/) :

Does Rollout comply to Apple's Guidelines?

        Yes. As per Apple's official guidelines, Rollout.io does NOT alter binaries. ... With over 50 million devices already running our SDK, it is safe to say that Rollout complies with with Apple's development and App Store guidelines.

Ouch. Just like the company's future is in danger.

<comment><USER25> The first time I saw Rollout I was shocked it wasn't already banned by the App Store. No matter what they say, I can't imagine how they could do what they claim to do without flagrantly violating the guidelines.

<comment><USER26> I'm guessing there are two things Apple is worried about. The first is using hot code push to change the _purpose_ of the app after release, e.g., switching a business app into a video game. The second is using hot code push to violate app store review guidelines, like the use of private APIs.

You can do hot "code" push techniques that allow the first but not the second, by letting apps update HTML and JS that calls back into pre-existing native code. That's what Cordova / PhoneGap does. I'd guess that Apple will just ban the app and the developer if they catch it.

It appears that Rollout started using some API that would enable it to do the second, and Apple is preemptively making sure that it doesn't happen. The wording of the rejection is based on passing computed parameters to introspection routines.

<comment><USER27> > The second is using hot code push to violate app store review guidelines, > like the use of private APIs.

I've never understood this part. Why doesn't iOS simply prevent apps from calling private APIs?

<comment><USER28> Preventing it in a technical way is far from easy: If your app calls public API X, which as part of its implementation calls private API Y, your compiler only needs a declaration of Y to output the function call / ObjC message send. Nothing in the language prevents it, and the code is executed natively unlike Java.

<comment><USER29> They control the software and the hardware though: seems possible to allow a specific region of memory (aka their public API) to call a specific region of memory (private API) and segfault for all the rest that does that?

<comment><USER30> Many private APIs are methods on objects which are part of public APIs, so there's no "region" of memory which cleanly corresponds to private APIs.

<comment><USER29> But they can theoretically create that as they own the entire chain; dev env, tools, OS, software, hardware (CPU included). I know it is not currently the case, sure, but they can do it was my point.

<comment><USER28> They "own" _a_ compiler, but not all of them.

Say they implement the scheme you mention in clang and the LLVM linker, so the function bodies of their public APIs end up placed in that privileged region of memory, and those of their private APIs end up in the restricted region.

Nothing prevents gcc from producing object files that tell the linker "this user function is part of Apple's public APIs". And nothing prevents people from using a different linker anyway, one that would put private API body functions out of the restricted region of memory.

The only real way to achieve that would be to move all their frameworks to the kernel, which would be all sorts of problematic.

<comment><USER31> > Say they implement the scheme you mention in clang and the LLVM linker, so > the function bodies of their public APIs end up placed in that privileged > region of memory, and those of their private APIs end up in the restricted > region.

Agreed that this design is fundamentally flawed, but that's because the coder is providing the implementations of private code. Providing that is Apple's job.

Put privileged code into a dynamically-linked library that Apple provides. Only code in that block of memory can call private APIs. Pretty straightforward to implement, and requires nothing fancy from the kernel.

Of course this only works if you can prevent the attacker from corrupting memory.

<comment><USER28> I don't know if iOS does randomization of loading addresses, but if so, that'd be a disadvantage.

And well, in any case they need to maintain compatibility with current apps for who knows how many years.

<comment><USER31> > I don't know if iOS does randomization of loading addresses, but if so, > that'd be a disadvantage.

Such a scheme wouldn't stop ASLR. The loader just needs to tell the verification code where it put the privileged libraries.

> And well, in any case they need to maintain compatibility with current apps > for who knows how many years.

Do they? I think Apple could easily order everyone to switch over to a more secure compiler with a one year deadline.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> Just imagine www didn't exist and Apple already had ios and apps. If someone came up with the idea of www and an app called web browser , would apple accept it in the app store? They would only accept it if they build it themselves.

At some point is there a risk that Apple may also start to ban the web browser, despite that it's under strict control on IOS?

<comment> grey-area This is why you don't build on someone else's platform.

Apple/Google/Platform Owner will always do what's right for them, not the customer, and not the developer, for example banning Amazon from selling books in their kindle app, not allowing competing browsers (they recognise the power of the web as a platform), not allowing competing sales mechanisms (where they don't get a cut), and here not allowing developers to update their apps except through the store mechanism. I have some sympathy with Apple here, and see why they're doing it (they have to control what software is installed for security reasons as well as platform protection), but this is all about control over what you install on your own device. Sometimes their actions will be in the best interests of customers, even if not the best interests of developers, but most of the time their actions are simply aimed at preserving their control of the platform and control of the money flowing through it.

The web is the one exception to this rule which works across all platforms and devices (because it is so dumb and simple), and has survived attempts to corral it to a walled-in commercial offering remarkably well.

<comment><USER33> Try making e.g. a game that is not on someone else's platform. Make a game that is not for PC or XBox or PS or Nintendo or iOS or Android or Facebook or Java or whatever. Count money. Oops, there isn't any.

Or, try making a Photoshop clone, CAD software or similar without being on someone else's platform. Oops.

"it don't work"

:)

<comment><USER31> > Make a game that is not for PC

Or is the right challenge "make a game for PC that isn't in the microsoft app store"? Which is in fact no hindrance at all.

It's not really "someone else's platform" just by using someone's software. They have to be in control.

</comment></comment></comment></comment><comment><USER34> I wonder if this is going to hit non native code push solutions like React Native? Or if Apple are going to start cracking down on apps like Facebook, Twitter or Pinterest that do a lot of A/B testing.

<comment><USER35> To date, Apple's Developer Program Guidelines states (in Section 3.3.2):

> Except as set forth in the next paragraph, an Application may not download > or install executable code. Interpreted code may only be used in an > Application if all scripts, code and interpreters are packaged in the > Application and not downloaded. The only exceptions to the foregoing are > scripts and code downloaded and run by Apple's built-in WebKit framework or > JavascriptCore, provided that such scripts and code do not change the > primary purpose of the Application by providing features or functionality > that are inconsistent with the intended and advertised purpose of the > Application as submitted to the App Store.

Personally, I think that Cordova hybrid apps will continue to be okay, but I don't know about something like React Native...

<comment><USER36> RN runs with JavaScriptCore.

<comment><USER37> rollout as well...

</comment></comment></comment></comment><comment><USER38> I really kinda see no problem with Apple doing this. Hack the endpoint the app checks for new code, push malicious code. Or fool the app into checking for new code at your server, push malicious code.

I mean I read the headline, thought this sounded eminently sensible, then read the story and saw it was a _framework_ for doing this, and my inner mental model of my security researcher girlfriend leaned forward, started rubbing her hands together, and wanted to start digging for those sweet new vulns.

</comment><comment><USER39> I wonder if Apple will apply this rule to everyone, which would be fair, or if they plan on letting big name developers like Facebook or Google continue to violate the rules without consequence.

<comment><USER40> They _should_ pull the Facebook app for this. But I'll eat my hat if they do.

<comment><USER41> Their guidelines specifically say that, with prior authorization, the prohibitions do not apply.

</comment></comment></comment><comment><USER42> You can accomplish some crazy stuff with hot code loading: use private APIs, get around privacy restrictions. In theory, there are a lot of guys reasons for Apple to prohibit this.

<comment><USER22> You can accomplish all of that without loading new code. Apple's private API checks, for example, are easy to get around if you're motivated.

</comment></comment><comment><USER43> There's a cynical part of me that thinks this is because Apple is going to announce a similar feature at WWDC

<comment><USER44> That doesn't seem likely. They 'just' reduced app review down to ~24 hours.

</comment></comment><comment><USER45> I've always questioned that 'hot code pushing' whenever I face an app that does it, like how on earth is it allowed to begin with ? they basically can send almost any functionality they want skipping Apple's reviewing all together !

</comment><comment><USER46> Hasn't this always been against the App Store terms? I thought the only language you were allowed to download code from the internet and run was Javascript on Apple's VM.

<comment><USER47> Rollout.io has been offering a product that leverages this to 'hotpatch' binaries, but it looks like this is now considered not in the spirit of the guidelines. Technicals here: [https://rollout.io/blog/under-the- hood-2016-update/](https://rollout.io/blog/under-the-hood-2016-update/)

It basically goes:

* add their SDK, which has the ability to swizzle(swap out the implementation for) arbitrary methods in your app

* the swapped in implementations use JavascriptCore to execute javascript you supply, wrapping or replacing the 'real' invocation of the method.

* their SDK checks on startup which methods to replace and downloads the appropriate JS replacements

This is, technically speaking, only using JavascriptCore.

<comment><USER48> That's actually quite a clever workaround to the current rules, but rather naive of them to think Apple wouldn't fight back at some point.

<comment><USER49> It's really sad, because that kind of stuff lets you fix bugs / mitigate outages in the wild without having to wait on apple's schedule.

<comment><USER50> This is true. The problem is bad actors can use this to bypass Apple's review. As an iOS app publisher I slightly regret this inconvenience. As an iPhone user, I appreciate Apple looking out for my security.

<comment><USER49> Apple's review isn't that useful in this case as a pre-check, it is possible to avoid it if you want. Apple review does automated code checks & a reviewer manually using your app. With that review process you can deliver executable code after the fact in any way you want and only get caught after the fact if it's even noticeable. You can even get sneaky and add some security exploit to make it look like a mistake.

It's much like the argument 'if you ban guns only criminals will have guns' and it's quite true in this case.

<comment><USER30> Given that Apple's automated review tools detect many ways in which executable code can be injected into apps, and OP's link is itself about that very thing - what you say is mostly false.

<comment><USER49> It was easy to detect because they are not to trying to hide it. They just have to check if the library exists.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER51> I'm curious if this has anything to do with the exploits that are in the recent Wikileaks dump. Perhaps Apple saw something in there that raised alarm and an impetus to close the loophole?

</comment><comment><USER52> I wonder what they define as "code." Uber often rolls out "Kittens for a day" style features, some of which are topical and can't have been designed before the previous app update.

<comment><USER53> A topical "special day" feature could easily be defined as a downloadable content blob with zero executable or interpreted code. They probably have a set of special event templates already coded into the application which can then be themed with a few images, colours and text strings.

</comment></comment><comment><USER54> I'm not an iOS developer, so I'm not sure what's possible, but am wondering about React Native apps (and similar technologies too). Here's a scenario:

\- you publish an app that creates collages;

\- user gives access to Photos;

\- you change your JS to upload all the photos to your server.

Substitute "photos" part to any iOS permission; isn't this security risk? Should it be allowed under current App Store ToS? Also, what's stopping your JS code from downloading binary code and injecting it via some iOS exploit into "native thread"?

<comment><USER55> There's not much to prevent that scenario from happening. There's now a "why" section in one of the app's descriptors where you need to describe what you're doing with the permission. So it's not enough to say "I want access to the photos". It's now "I want access to the photos so that I can put them on the screen and let you draw funny pictures on them."

But there's little to prevent you from lying about it, and there are so many iOS platform technologies out there now (native, PhoneGap, React Native, AIR, Xamarin) that there's probably no way for Apple to see what you're doing in an automated way.

</comment></comment><comment><USER56> From my understanding people are giving rollout push rights to their app store accounts? So rollout can hijack all the apps it controls? It's a hell of a central authority, a security nightmare waiting to happen.

<comment><USER57> No, it allows apps to be modified by the apps pulling JS code from rollout's servers. App reviews would be way too slow, and they are exactly the problem that rollout solves. However, review times have improved a lot since then.

ADDITION: It works by "swizzling" methods, which is a valid mechanism in Apple's runtimes (like in Ruby or many other dynamic languages). In Swift, this will only work in subclasses of NSObject or its decendants, because only then message dispatch is used.

<comment><USER56> Ok, so there's no direct access to your App Store but idea is same - <USER2> can "hot fix" aka pwn all users at once. I'd be angry if I were apple too.

<comment><USER57> Indeed, I always wondered how Rollout would not same day be rejected by Apple.

</comment></comment></comment></comment><comment><USER58> How does apple understand whether the app can change behaviour according to external factors. Maybe in other words, what is a "behavior change"?

For example, google has Tag Manager [1] which I believe is mostly used for managing small UI related changes. Is there a clear documentation or distinction about that?

[1] [https://developers.google.com/tag- manager/](https://developers.google.com/tag-manager/)

</comment><comment><USER26> > _any code which passes arbitrary parameters to dynamic methods such as > dlopen(), dlsym(), respondsToSelector:, performSelector:, > method_exchangeImplementations(), and running remote scripts in order to > change app behavior or call SPI_

I would have expected dlopen and dlsym are blacklisted - you can trivially use dlsym to access any blacklisted API. Similarly, I thought SPI ("system programming interface" = private API) _was_ all blacklisted. Am I misreading the message?

That said, if this is what they're focused on, it seems like it actively does not impact any apps that hot-push HTML code (e.g., PhoneGap / Cordova).

If the only reports are coming from Rollout.io, my guess is that the latest Rollout SDK uses one of these functions (I'd bet method_exchangeImplementations(), i.e., swizzling) with a dynamic parameter, and that the SDK can be changed to just stop doing that.

</comment><comment><USER3> Hi all (Erez from Rollout here) –I appreciate the discussion. Here's our full statement – please weigh in with any questions

[https://rollout.io/blog/rollout-statement-on-apple- guideline...](https://rollout.io/blog/rollout-statement-on-apple-guidelines/)

</comment><comment><USER59> good, this sort of stuff screams of abuse potential.

devs should re-submit their code to apple, instead pushing "fixes" to phones. i guess it's fair to assume 99% of those pushes are safe (80%? guess it's more like 'benefit of the doubt'), but that 1% the escapes scrutiny is the one piece that makes the whole platform shaky, and honestly, poses a major attack vector. i wonder how often this was abused.

as to service like rollout.io, it's a service that was never supposed to be. especially if it serviced hundreds of apps - as a security minded indv. i shudder at the thought of what might have slipped through.

edit: after digging into rollout.io and finding out it's based in telaviv, is it wrong to speculate about origins and real purpose of an israeli company that specializes in injecting code into iphone applications?

</comment><comment><USER60> "Oh look, I found this tunnel under the border, I'll use it to feed the birds on the other side. I swear to god I'll never use it to smuggle drugs or people"

It is too bad people is using it for good causes but the hole has to be closed. Sorry guys.

</comment><comment><USER61> tldr - appears to affect rollout.io customers (at least for those who have replied to the thread so far).

</comment><comment><USER62> We haven't noticed any issues with AppHub, our service for dynamically updating React Native JavaScript code.

We always felt this day would come, however, so we switched directions.

</comment><comment><USER63> I checked again rollout.io Disrupt presentation (great pitch btw) and the first question they get (Alexandra Chong) is "is it going to be ok with AppStore policies": [https://techcrunch.com/2015/09/22/rollout-io-puts-mobile- dev...](https://techcrunch.com/2015/09/22/rollout-io-puts-mobile-developers- back-in-control-of-their-apps/)

</comment><comment><USER64> What will happen to YouTube? YouTube has been pushing new functionality ahead of updates for me recently. For example, the new "double tap to rewind 10 seconds" feature appeared at random one day (without an any updates)...then eventually the feature is announced in an App Store update.

Or is the app review process more subjective?

<comment><USER65> They might have achieved that by pushing it in silently over time and utilizing feature flags. Only going live in an app store update once it was rolled out to everyone.

</comment></comment><comment><USER66> Should have been banned long ago, why would they have allowed an app to alter major behaviors post review?

</comment><comment><USER67> I'd say this is only going to further the arms race. One simple way around this would be to intentionally introduce a bug with a "controlled" exploit that lets you send a specially crafted data packet to your app, and execute shell-code of your choice.

</comment><comment><USER68> I've recently been looking into React-Native. I'm hesitent to commit because i believe there's 'hot code push' potential and Apple will be a b __*h about it. I not sure if this is the case thou.

<comment><USER69> > i believe there's 'hot code push' potential

It's called CodePush, and it's a plugin for React Native (does not come with it). It is developed by Microsoft: [https://microsoft.github.io/code- push/](https://microsoft.github.io/code-push/)

Doubt it would get taken down.

<comment><USER68> Interesting, thanks

</comment></comment></comment><comment><USER70> Non iOS/Apple developer here.

So, with this "hot code push", is it also possible to update an app (adding new features), and not only bug fixes, directly?

If yes, then sounds like you are trying to circumvent the App Store QA process.

</comment><comment><USER71> Just ditch Apple. The obnoxious attempt to ban any kind of customization is sickening. Apple like to shoot in their own foot by making life miserable for developers.

<comment><USER72> But users have no idea how miserable life behind the iron XCode curtain is, so it will continue forever.

</comment></comment><comment><USER21> That game that is topping the charts "Legacy", explicitly says when you start it that it's downloading patches. Wonder why it isn't blocked?

<comment><USER73> Patches could be assets - updated map data - updated textures - updated AI scripts? I don't think these need a full app store update as it's not changing the game from a game to a dating app (for example).

<comment><USER74> Still, how do they avoid someone writing an ad-hoc interpreter and reading code from e.g. PNG images? Data == code, as we know.

</comment></comment></comment><comment><USER75> I don't see Apple blocking React Native, too many big players using it in production.

If you use hot code push together with React Native, then you're borked.

</comment><comment><USER76> A day after the Vault 7 leaks. Well well well

</comment><comment><USER77> Another big worry is analytics platform like 'AppSee' that is clear violation of consumer privacy.

</comment><comment><USER78> "Starts"? I thought this was always a rule. Maybe they're only starting to enforce it now...

</comment><comment><USER79> Hot CIA back door push is a misfeature in any app, and Apple are doing the right thing here.

</comment><comment> d--b Could this have anything to do with Wikileak's release of iOS hacks by the CIA?

<comment><USER80> Probably not, the timing is too tight, and if Apple were aware of active exploitation, they would probably compeltely remove / block affected apps, instead of giving the devs a notice to improve the next release.

</comment></comment><comment><USER81> Didn't Firebase just introduce Remote Config which touts this very thing?

<comment><USER82> AFAIK Remote Config is just a server side key value store with customisable values based on audiences (e.g. random 50% for A/B testing, all people from Country X). This means all behaviour changes will require code to be deployed in the first place.

Also, from Firebase Docs[1] "Don't attempt to circumvent the requirements of your app's target platform using Remote Config."

[1] [https://firebase.google.com/docs/remote- config/](https://firebase.google.com/docs/remote-config/)

<comment><USER81> From this....

[https://www.youtube.com/watch?v=_CXXVFPO6f0](https://www.youtube.com/watch?v=_CXXVFPO6f0)

"Firebase Remote Config allows you to change the look-and-feel of your app, gradually roll out features, run A/B tests, and deliver customized content to certain users, all from the cloud without needing to publish a new version of your app."

<comment><USER82> With hot code pushing, you're deploying newly written code/functionality, post release (opening possibility of up MiTM attacks etc).

With Remote Config you deploy the code, then decide what to show to users post release. This gives Apple a chance to review all the code submitted to the App Store.

In the case of rolling out features an A/B tests, you'd make a release including a feature, but only enable it x% of your users using RC. You can then obviously enable it for everyone if it passes your A/B test or if you're happy its working.

</comment></comment></comment></comment><comment><USER83> React Native allows you to replace the JS bundle, will this be affected?

</comment><comment><USER84> This has always been a requirement for Apple apps, hasn't it?

</comment><comment><USER85> What about Microsoft's infamous Code Push?

</comment><comment><USER86> Does this mean all Cordova apps may be banned?

<comment><USER14> Not necessarily. From the Apple Developer Program License Agreement:

> 3.3.2 An Application may not download or install executable code. > Interpreted code may only be used in an Application if all scripts, code and > interpreters are packaged in the Application and not downloaded. The only > exception to the foregoing is scripts and code downloaded and run by Apple's > builtin WebKit framework, provided that such scripts and code do not change > the primary purpose of the Application by providing features or > functionality that are inconsistent with the intended and advertised purpose > of the Application as submitted to the App Store.

</comment></comment><comment><USER87> Stuff like this is one of the big reasons I am a fan of web apps over mobile apps. Letting apple or google have control over this channel is just too risky for me.

<comment><USER88> You've literally got things upside-down.

</comment></comment><comment><USER89> The Unfree web.

</comment><comment><USER90> Does this effect React Native apps?

</comment><comment><USER91> Understandable, but there is a deeper problem of course - the app store model is broken for apps that need hotfix capabilities (aka enterprise).

We've been meeting with Apple on this topic for years and continue to sideload our app as we need to meet SLAs with our customers. They sign the binaries with their dev certificates, which violates Apple's guidelines too.

But, alas, once you have critical mass in a vertical even mighty Apple gets cold feet about shutting your customers down.

Why Apple is not able to offer a separate way for certified and audited dev shops to hotfix their iOS apps is beyond me. SAP, MS, IBM - a shitload of big shops would love to pay for this privilege.

<comment><USER92> 'Enterprise' always needs things, and then when these required things are not available enterprise makes do with what is.

In this case it isn't required at all though because Apple allows enterprise to sideload apps outside of the review process.

<comment><USER91> But not as a vendor.

Right now we get the certificates from out customers, sign the individual binaries. Then distribute through our own infrastructure.

We have our own update mechanism (basically hot code push), cannot have the customer's own IT shop be a barrier to deploy the fix. User sync their apps, if there is an upgrade that gets done inbetween the normal data/content sync.

</comment></comment></comment><comment><USER93> Oh, Mario Run! What are you gonna do?

</comment><comment><USER94> About time, as an user it's fucking annoyng when you download an app but will refuse to work unless you're online even when it has zero needs for it

<comment><USER95> To be fair that's just bad UX, there is no necessity for apps using rollout to access the internet as (I hope) rollout caches the app.

</comment></comment><comment><USER96> The solution is fairly simple: just stop releasing software on that platform. There are millions of customers on more open platforms, so there's really no need to support them anyway.

<comment><USER97> All of life's problems are simple when suicide is your backup plan.

<comment><USER98> Boycott is a valid response no matter how much you try to make false analogies. Pulling app out of app store is by no means equivalent to suicide. At most you change your business.

<comment><USER99> Right, like Uber, Snapchat, Facebook, Clash of Clans, Pinterest, Whatsapp, Instagram, Twitter, Waze, Shazam, Tinder, Match, YouTube, and basically every other app out there pulling out of the App Store would _not_ be suicide.

"At most", those companies would just have to "change their businesses".

<comment><USER100> If all those companies did pull out, then it would be the end of Apple.

<comment><USER99> Absolutely not. Apple was fine long before these companies came into existence, and Apple will long outlast these companies. New companies would come in to fill the spaces these companies will have left in days.</comment></comment></comment></comment></comment></comment>


Ask HN: Good Books on Climate Change? - <AUTHOR> I am taking on a special information diet of sorts and part of my process is to consume long-form materials on current events instead of perusing articles that I'll forget about the next day.  What books are good scientific, political, and economic overviews of climate change? <comment><USER2> Not a book, but a paper that frames things in terms of a global cumulative emissions budget: Friedlingstein & others -- "Persistent growth of CO2 emissions and implications for reaching climate targets"

Not directly about climate change, but about renewable energy: Mackay -- [https://www.withouthotair.com/](https://www.withouthotair.com/)

Not about how to fix climate change, but an exploration of some factors as to why we're not working to address the problem (propaganda from business groups...): Higgs -- Collision Course

not about climate change, but the general problem of how environmental limits, resource depletion, cumulative pollution limits population growth and the dynamics of different ways population could crash or oscillate or level off: meadows & others -- the limits to growth

McKenzie Funk -- Windfall: The Booming Business of Global Warming

</comment><comment><USER3> Someone else suggested this book, a summary of hundreds of scientific climate change papers projected environmental global and local effects categorized by each celsius degree increase. It covers broad stroke scientific, political, and economic changes due to climate change.

[https://en.wikipedia.org/wiki/Six_Degrees:_Our_Future_on_a_H...](https://en.wikipedia.org/wiki/Six_Degrees:_Our_Future_on_a_Hotter_Planet)

Project Drawdown ranks different projects based on impact to climate change: [https://www.drawdown.org/solutions](https://www.drawdown.org/solutions)

</comment><comment><USER4> I loved "Climate Wars" by Gwynne Dyer: [https://www.amazon.com/Climate-Wars- Fight-Survival-Overheats...](https://www.amazon.com/Climate-Wars-Fight- Survival-Overheats/dp/1851688145)

If you are looking for a fictional take, check out "The Water Knife" by Paolo Bacigalupi: [https://www.amazon.com/Water-Knife-Paolo- Bacigalupi/dp/08041...](https://www.amazon.com/Water-Knife-Paolo- Bacigalupi/dp/080417153X)

</comment><comment><USER5> The Skeptical Environmentalist by Bjorn Lomborg:

[https://www.amazon.co.uk/Skeptical-Environmentalist- Measurin...](https://www.amazon.co.uk/Skeptical-Environmentalist-Measuring- State-World/dp/0521010683)</comment>


Rand Paul Begins Filibuster of Patriot Act - <AUTHOR> http://dailycaller.com/2015/05/20/rand-paul-begins-filibuster-of-patriot-act/

<comment><AUTHOR> You can watch a livestream of the filibuster here: [http://floor.senate.gov/MediaPlayer.php?view_id=2&event_id=3...](http://floor.senate.gov/MediaPlayer.php?view_id=2&event_id=320)</comment>


Marcus Hutchins pleads not guilty in US - <AUTHOR> http://www.bbc.co.uk/news/technology-40923065 <comment><USER2> Does anyone have a technical breakdown of what code he admits to have written? TIA

I'm late to the party and most of the articles I've seen so far focus more on the person and WannaCry as opposed to the 2013-2014 aspect.

<comment><USER3> Apparently it's about this code: [https://www.malwaretech.com/2015/01/inline- hooking-for-progr...](https://www.malwaretech.com/2015/01/inline-hooking-for- programmers-part-2.html)

This is function hooking code. It's useful when you need to change the behaviour of an application, by redirecting a function call to your own function.

Like any piece of code it has both legitimate and nefarious uses. However, function hooking is very basic stuff.

Anyone who has ever tried to learn how things work under the hood will have written function hooking code before.

<comment><USER4> What's your source on that being the code in question?

<comment><USER5> Not OP and idk but do you think Rob[0] it referencing this hooking code or something else on his Github[1]

[https://twitter.com/ErrataRob/status/893197917493882880](https://twitter.com/ErrataRob/status/893197917493882880)

[https://github.com/MalwareTech/BasicHook](https://github.com/MalwareTech/BasicHook)

</comment></comment></comment></comment><comment><USER6> This headline is editorialised. Some basic OSINT will show he also sold a banking trojan previously, which is what he is facing charges for.

<comment><USER7> That is an allegation which has not been proven without a doubt.

The headline, while complimentary, makes sense as it identifies him in the way most folks would recognize.

<comment><USER8> That's the point of a criminal conspiracy: to be well-known only for positive things, and for nobody to know about your involvement in negative things.

Obviously, he hasn't been found guilty of anything, and you're entitled to argue that the evidence suggests he isn't. The only thing you can't reasonably argue is what you've tried to argue here, which is that we should judge this person by what they were previously best known for.

<comment><USER7> The only judgement which should occur at this point is in the courtroom. I am making no argument beyond a reply to this part of the comment:

> This headline is editorialised.

<comment><USER9> >The only judgement which should occur at this point is in the courtroom.

But why? Why can't other people judge him for him previously selling other malware similar to Kronos under the handles "Gone With The Wind" and "iarkey" on Hackforums?

Surely it's not for lack of evidence as anyone with access to google can easily verify this.

If he's being framed, we're talking about at least a 7 year long operation to do so: [https://i.succ.in/CWcDhXxi.png](https://i.succ.in/CWcDhXxi.png)

<comment><USER7> The context was:

> The only thing you can't reasonably argue is what you've tried to argue > here, which is that we should judge this person by what they were previously > best known for.

I did not try to argue that at all, so I was clarifying my opinion. Nobody will stop you if you choose to judge him based on that allegation, I am choosing to wait on that due to the fact that it will get figured out (with actual evidence either way) in court.

<comment><USER8> I don't think I wrote this clearly and so I don't blame you for misunderstanding what I'm saying.

Judge guilty, judge innocent, don't judge at all: all of those are reasonable options open to you.

The only option I am pushing back on is the one that says the only reasonable way to frame somebody is in terms of the good thing they're best known for. Because, of course, it is in the nature of criminal conspiracies to work hard _not to be known for them_.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> You would think the UK government would help him out here, given what he did for us.

<comment><USER8> You think the UK government would intervene to stop the trial of someone accused of operating a conspiracy to spread banking trojans? Why?

<comment><USER10> Because he's not just a 'someone', he's a hero for stopping the disgusting attack on the NHS and letting doctors and nurses get on with their job of saving lives.

<comment><USER8> This doesn't make any sense. It's not how justice works. You can't do one useful thing to excuse a series of grave crimes.

<comment><USER11> I know this probably isn't what you meant, but it's actually often the case that doing useful things helps people get over the other things you did, see Francis Drake, any number of founders of post-colonial and early 20th century countries, conquistadors/founding fathers/revolutionaries, etc.

In short, justice is what most other influential people deem just, not some universal measure of conduct.

Those responsible for the firebombing of Dresden never stood trial, because the victims belonged to the losing side. The "scientists" of Unit 731 never stood trial.[1] Only 13 out of 24 directors of IG Farben were found guilty and all were released early.[2]

The church effectively killed hundreds of thousands (very conservative guess) by telling people not to use condoms. No one was tried.

1 - [https://en.wikipedia.org/wiki/Unit_731#Surrender_and_immunit...](https://en.wikipedia.org/wiki/Unit_731#Surrender_and_immunity)

2 - [https://en.wikipedia.org/wiki/IG_Farben#IG_Farben_Trial](https://en.wikipedia.org/wiki/IG_Farben#IG_Farben_Trial)</comment></comment></comment></comment></comment>


Ask HN: How did you learn to touch type as a programmer? - <AUTHOR> I've done some typing courses to get to grips with the main keyboard, but I still often make mistakes when programming and using e.g. curly braces and parentheses. Moreover, I have an 82" wingspan and big hands which make things even more awkward.
I want to get to the point where typing is so effortless and mistake-free that it doesn't interrupt my thought process.
Not sure if this an ergonomic issue or just a case of practice, practice, practice.
Is there anything anyone did to master touch typing beyond just standard practice? (esp. tall and lanky people) <comment><USER2> I am tall, not lanky. I never properly learned to touch type, at least not via Ms. Mavis Beacon or Mario's teachings. I found practice was very useful, but with programming in particular, it's been my experience that consistent speed helps me get into a flow. If I'm not sure what I'm going to type next, my brain focusing on what to tell the computer to logically do next 'crosses the stream' with what last statements I want to write out and causes typos.

As far as general touch typing goes, my dad showed me the keyboard he connected to the Gateway Win 98 box and said "that there is an IBM Model M keyboard, and if you learn how to use it right, it will last your whole life".

I was inspired to learn to type without looking at the keyboard, so over the age 9-12 years, I worked on it. These days, I don't have to look at it much, but still do things like typing 'ahve' instead of 'have'.

Oh, and that IBM keyboard was lost in a move, since replaced by a identical- if-i-didnt-otherwise-know keyboard I 'disposed' for my work with the evilest grin.

</comment><comment><USER3> Just the daily use of a keyboard has given me the muscle memory to touch type. I lose my hand placement frequently as my work keyboard doesn't have the bumps on the home row, so the start of every sentence I take a glimpse at the first key I'm going to press.

I find with programming I make an incredible amount of mistakes as I'm typing and thinking ahead at the same time, leading to me to spamming the backspace every few words (maybe I should pay more attention).

To get good at touch typing, I believe it's just practice without getting lazy, as in, pay attention to the fact you're touch typing, maintain good habits, and prevent bad habits.

</comment><comment><USER4> 40 years or so as a professional programmer and I never learned to touch type. Never found slow typing to be a bottleneck. _What_ to type is the hard part.

</comment><comment><USER5> I learned how to type on a typewriter in a typing class in middle school, early seventies. #OldSchool

What helped me get good (but not excellent) was to write lots of English. Lots of that was/is email. Lots more than 140 characters at a time.

</comment><comment><USER6> I played typing games years ago. Those force you to focus on quickly & accurately hitting the correct key.</comment>


Edge sends full URLs of pages visited to Microsoft - <AUTHOR> https://mobile.twitter.com/scriptjunkie1/status/1152280517972299777 <comment><USER2> Eric Lawrence (PM on Edge, previously on Chrome, previously author of fiddler) showing screenshots of documentation that explains all that, and saying it's been documented this way for 14 years:

[https://twitter.com/ericlaw/status/1152933704198758401](https://twitter.com/ericlaw/status/1152933704198758401)

<comment><USER3> ...and for 14 years no ordinary user has understood what those default settings do, instead assuming "their software provider wouldn't do that..."

<comment><USER4> I think you're making a big assumption that ordinary users care if Microsoft knows what URLs they visit--how many of them use blockers or another technology to opt out of e.g. Facebook tracking?

<comment><USER5> Ordinary users don't know what a URL even is. But they do assume every site they visit isn't being logged by Microsoft, much like they assume their car's manufacturer isn't recording the places they drive to using GPS.

"Users don't care" is such an intellectually dishonest argument when users aren't technical enough to understand the subject.

<comment><USER6> Maybe we should differentiate "users understand and don't care" against "users don't understand and don't care".

On one hand, a TOS usually describes privacy implications. On the other hand, there's no accountability that a user has understood or even read the TOS. Is it unreasonable to assume people will read the fine print?

<comment><USER7> > Is it unreasonable to assume people will read the fine print?

Unequivocally, yes. Even if someone hypothetically had enough time to read every TOS they've agreed to I would venture to guess the average user wouldn't be able to comprehend most of the terms[1] anyway. Disclosure documents are written by lawyers (corporate CYA) for lawyers (regulators, plaintiff's counsel, judges).

The law, however, disagrees with me entirely.

[1] Edit to clarify I mean "terms" as in the terms _of the agreement_

<comment><USER6> Delegating privacy rights feels like delegating monetary rights. As in, negotiating contracts for payments. This is coming from the perspective of a simple person trying to understand this complexity. Anytime I sign complex and impactful contracts, it's usually done in person with physical paper and a general understanding between both parties. An online agreement feels like scam artist's work, only after we've realized the value of our personal data. Maybe we're giving too much away at the notice of typed words? We're essentially giving away resource because we didn't realize the importance of it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Is there even a "pure" browser anymore? By that, I mean one which by default will do this: if I enter a URL in the address bar, it will fetch that page and its associated resources. If I click a link on a page, it will fetch its destination (this is obviously a simplified view, ignoring things like JS on the page etc.) No other network activity, no "recommendations", no other attempts to be "smart" or "helping" by doing anything beyond "pure" browsing.

I see a lot of this extra functionality being justified in the name of "security", but I don't think the gradual erosion of personal responsibility and agency that results is something which should continue.

"The road to hell is paved with good intentions."

<comment><USER9> Firefox might not meet your definition but with a few extensions (Containers, NoScript, uBlock origin) it's quite good at protecting your privacy.

<comment><USER10> The only thing is they integrate things like pocket and they're putting some other things in soon.

<comment><USER11> Pocket is part of Mozilla

<comment><USER12> And it still is not open-sourced, two years and five months after the acquisition: [https://github.com/Pocket/extension-save-to- pocket/issues/75](https://github.com/Pocket/extension-save-to- pocket/issues/75)

For comparison, it took Red Hat less than two years to open source Ansible Tower.

</comment></comment></comment></comment></comment><comment><USER13> No one should be surprised by this. Microsoft is Google, just with a price tag attached. (Google services are usually free of charge because they mine your data and target you with ads; Microsoft has discovered the concept of double- dipping and has now joined the party, while still charging for Windows.)

Getting you to sign into your computer with a Microsoft account is all about tracking and monitoring everything you do all of the time and selling a record of it to the highest bidder.

</comment><comment><USER14> Edge is the number one browser in the world for installing chrome.

<comment><USER15> Doesn't Chrome send your entire browsing history to Google as well?

Edit: I thought this was a well know fact and if it isn't I might have been to harsh about Google and Chrome.

Edit 2: Thinking about it and searching a bit I conclude that IIRC Google at least used to have access to your browsing history as part of syncing it unencrypted.

<comment><USER16> Everything you type into the address bar gets considered for possible completion, right? And part of that quite possibly entails sending it off to Google servers which take a stab at finding completions for it. Your claim seems plausible at least.

<comment><USER17> Yes, there are some options under chrome://privacy/settings that suggest they send full or partial URLs:

\- _Use a web service to help resolve navigation errors_

\- _Use a prediction service to help complete searches and URLs typed in the address bar_

and then there's

\- _Use a web service to help resolve spelling errors_

whose description suggests it sends more than URLs.

<comment><USER18> And, if I recall right, you're asked if you want search suggestions in the omnibar the first time you use it for that purpose.

<comment><USER16> Does that prompt effectively explain its impact to nontechnical users?

</comment></comment></comment></comment></comment></comment><comment><USER19> I assumed every browser did this as a part of their safe browsing features. Or is this different somehow?

<comment><USER20> Following tweets explain that other browsers send an hashed URL instead. (but I guess it's easy to associate the hash with actual URLs)

<comment><USER21> Other browsers use a _truncated_ hash. Easy enough to match to a known list of bad sites, but exceptionally difficult to reverse engineer a list of sites the user has visited.

<comment><USER22> Those hashes have to be essentially unique to prevent blocking good sites erroneous;y, and as such are easily associated to actual sites when you're the scale of MS or Google.

<comment><USER23> Not if there's an other layer of verification locally. Then you can allow a few false positives with the hash on the remote and they'll get discarded when the full hash is compared locally. That being said 32bits of information seems like quite a lot and can probably used to match the original URL fairly accurately.

<comment><USER16> You also need to consider the greater context. Suppose my history shows I sent a hash that could be one of 100 different known URLs. One of them is about model airplanes, but there is no way to know I picked that one. Chance I like model airplanes? All else being equal.. call it 1%

But what if over the next hour I continue to send hashes with random subject matter sets that include model airplanes each time. Suppose the intersection of the possible subject matters shrinks with each additional hash, quite possibly contains only model airplanes.

I visited 100 URLs in one hour. For each URL there are 100 others with the same hash but independent topics. Lets say there are 10,000 known topics, but every hash I sent has model airplanes associated with it. Now what are the chances I like model planes?

It seems clear to me that this scheme, with logging, reveals a lot in theory. But _maybe_ solving this problem in practice would cost more that the data is worth. For now.

<comment><USER24> You skipped a factor, in Safe Browsing Update API (the mode actual web browsers like Firefox use) that step where you send a 4 byte prefix only happens when the prefix already matched a local hotlist.

So if you visit 100 URLs in an hour, and using the local hotlist allows your browser to discard all but 1 of those URLs as definitely not bad, that's only one URL prefix checked against Google, not 100 so there's no triangulation.

And the actual number isn't 1-in-100, that's why they picked 4 byte prefixes. I haven't actually checked, but by eyeball from playing with this data for work I would guess 1-in-a-million.

So, you visit 100 URLs about model planes, one of them happens to be a 1-in-a- million match to a possible badware site, your browser sends the 4-byte hash prefix to Google, it gives back the 4-byte prefix of the badware site it was worried about which is different, your browser goes "Phew, good" and nothing happens.

There's just not really an opportunity for tracking here.

<comment><USER24> Ugh, editing goof - that last bit of my explanation is wrong, Google sends the whole SHA256 hash of the bad site's URL and your browser compares -that- to the full hash it calculates for the model plane site. The four byte prefix will be the same of course, if it wasn't we wouldn't get this far.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> Can this be changed to the normal twitter URL, not the mobile version?

<comment><USER26> When I removed the "mobile" it looks exactly the same. I guess there is no non-mobile version of Twitter anymore.

<comment><USER27> There's a super-fast, no bullshit, mobile-friendly, absolutely wonderful version of twitter you can get if you disable javascript... (i've only used it through tor tho)

<comment><USER28> I'm not sure about "super-fast" since, every time I visit twitter w/o JavaScript, I'm forced to click thru the message:

 _We 've detected that JavaScript is disabled in your browser. Would you like to proceed to legacy Twitter?_

And this annoyance persists. Click on a twitter link within the twitter website and you get the message again. And again. It's definitely a dark pattern meant to annoy you into enabling JavaScript.

</comment></comment></comment></comment><comment><USER29> Doesn't it send full URLs anyway when you're signed into Edge or Chrome to sync your history?

</comment><comment><USER30> Which is why I always harden Edge after setting up Windows by disabling SmartScreen

<comment><USER31> You could just use another browser like Firefox. :)

<comment><USER32> AFAIK Mozilla does the same.

<comment><USER33> Mozilla does not send full URLs to a third party. As mentioned in the thread, they use "4-byte URL hash prefixes."

Documentation: [https://developers.google.com/safe-browsing/v4/urls- hashing](https://developers.google.com/safe-browsing/v4/urls-hashing)

(Disclosure: I work for Google but have nothing to do with the safe browsing API.)

<comment><USER34> Wait, this is not happening locally, against bloom filters or something?

<comment><USER35> There is a first step which uses bloom filters, and if the filter gives a result, it is hashed and the hash is sent to the google service to double- check.

That being said, a four byte / 32 bit hash is enough to almost uniquely identify a website. There number of 32 bit numbers and websites is roughly the same order of magnitude. It's a problem without a good solution because if you create many collisions then you also generate plenty of sites falsely reported as phishing and which admin would want _that_ to happen on their site. If you avoid creation of collisions, you have this identifyability problem.

There is this CRLite proposal [1] using layered bloom filters to stop reliance on web services. Maybe it can be adopted for phishing sites, as well.

[1]: [https://ieeexplore.ieee.org/document/7958597](https://ieeexplore.ieee.org/document/7958597)

<comment><USER36> >That being said, a four byte / 32 bit hash is enough to almost uniquely identify a website. There number of 32 bit numbers and websites is roughly the same order of magnitude.

Why not send less bits (eg. 24 bit) of the hash?

<comment><USER37> The utility of the hash for a user and some potential attacker is the same. Yes, passing 8 fewer bits means that they have 256 times more possible sites you might have visited. But it also means that you get 256 times as many false positives of websites being labeled as phising. This is what GP meant by it being problem without a good solution.

One possible option is to do what haveibeenpwned does, where you give fewer bits and then locally check. That would be a good improvement to the system's privacy, but you probably want to avoid downloading the hashes of every malicious website that starts with the given 3 bytes (I'd assume the list is quite large) for every page load.

<comment><USER24> SafeBrowsing already does the thing you're describing as a "possible option".

Say I go to [https://fakebank.example/security/login](https://fakebank.example/security/login) and Google has decided all of fakebank.example is a phishing site.

My browser computes [among other things] SHA256('fakebank.example') and then it snips off the first four bytes and compares that to a large dataset it got from Google. It fetches updates to this dataset every few hours. Sure enough the four byte prefix is present in the dataset.

So, we've got an alarm - it calls Google, but it doesn't tell them it's thinking about [https://fakebank.example/security/login](https://fakebank.example/security/login) at all, it just tells them the 4 byte prefix. Google responds with a list of full SHA256 hashes beginning with that prefix that it considers _right now_ to be phishing. The list might be empty (maybe fakebank.example was actually a Greek yoghurt company subject to a PHP 4.x attack, and they upgraded PHP and removed the phishing site so now it's fine) but if it has the entire SHA256 hash we calculated then I get an alert telling me that my browser thinks this is a phishing site and I might want to not visit.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> Not to defend Microsoft, but SIDs are non unique. I think theyre only guaranteed to be unique per AD forest with the addition of the RID subauthority. Lots of domains are domain.local or other such commonalities and so may have duplicates. Microsoft would know this, so the intent does not appear surveillance or data collection.

<comment><USER36> According to wikipedia, a SID looks like this

        S-1-5-21-3623811015-3361044348-30300820-1013

The 3 long numbers in the middle are called "Domain or local computer identifier". Further down it says that each of those numbers are encoded as a 32 bit integer. Assuming they're randomly generated, that's 96 bits of entropy, which is more than enough to uniquely identify every computer on the planet[1].

[1] There might be a _few_ duplicates due to the birthday paradox.

</comment></comment><comment><USER39> This is one of the reasons I don't use chrome. Google tracks which search links I click on any browser but I assume they simply track everything else done with Chrome.

</comment><comment><USER40> Not so easy to do this mitm trick with Chrome, it has google certs pinned down. I think Chrome sends no less info to Google.

</comment><comment><USER41> Poster might use preview versions, where Microsft does these things (not just Edge) if I recall correctly.

</comment><comment><USER42> Anyone know if "full URL" here would include a hash from the url?

</comment><comment><USER43> Every time I see people on HN campaigning for Microsoft as some kind of reformed tech company that has seen the errors of its past and turned into a force for good, something like this comes up.

Same old Microsoft. Second verse same as the first.

<comment><USER44> The good part of Microsoft is the division responsible for languages, compilers and cloud. Meanwhile an old Microsoft makes Windows, Office, etc.

While the latter has improved somewhat, only the former has reformed.

<comment><USER45> >The good part of Microsoft is the division responsible for languages, compilers and cloud.

Putting their telemetry in your compiled binaries is ... real good? Marketing is the only thing that changed.

<comment><USER44> Yes. I have absolutely no problem with the way that works. It's clearly spelled out how it works and how it's configured. Seems few who actually use these tools have problems with this...</comment></comment></comment></comment>


Ask HN: Are GDPR cookie popups useful or just annoying? - <AUTHOR> <comment><USER3> I feel like they are just annoying. Some of them have made the UI so weird that it's impossible to know if I have turned them off or not. Also there are some cookies which are called "Functional" and then they give 7000 word essays on what they are. If I had enough time I could customize this but I don't have the time to review it for all the websites.

It would be so nice if there was a single plugin which everyone used and I can plan in central ui.

<comment><USER4> _"Some of them have made the UI so weird that it 's impossible to know if I have turned them off or not. Also there are some cookies which are called "Functional" and then they give 7000 word essays on what they are."_

Neither of those are legal. [https://gdpr- info.eu/recitals/no-32/](https://gdpr-info.eu/recitals/no-32/):

 _"If the data subject's consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided."_

</comment></comment><comment><USER5> My current policy for "Cookie Consent" dialogues:

1\. Fire up uMatrix and globally block cookies for domain.

2\. Fire up uBlock Origin to block element on page.

3\. Self-Destructing Cookies for edge case motherlovers.

Remember, boys and girls and all that lieth betwixt and beyond: FIRST pillage THEN burn!

[https://mastodon.cloud/@dredmorbius/102292441272732943](https://mastodon.cloud/@dredmorbius/102292441272732943)

</comment><comment><USER6> Annoying and useless. These kind of popups have become so widespread that a regular internet user pretty much agrees to anything as soon as the pop up. Private mode users are being trolled for opting for privacy with this regulation.

</comment><comment><USER7> They're supposed to be useful, ie the site should not be stalking you until you say yes, the consent prompt should not be misleading (no dark patterns) and service shouldn't be denied until you say yes (I'd argue taking over the entire page and preventing you from browsing until you make a choice would be against the regulation).

Note that this is not just about cookies but about any kind of stalking; browser fingerprinting, local storage, etc. It's more of a legal thing where you gave them permission to track you as opposed to a technical restriction, so a browser-based solution isn't really an equivalent (you can block their cookies but they'll still fingerprint your browser).

The problem is, a lot of them are badly implemented and load the trackers regardless, a lot are badly configured and consider Google/Shitbook as "necessary" cookies you can't opt-out of, and most of them are a pain to opt- out (with Yahoo/Oath - the cancer of the internet - in prime position - <USER2> GDPR flow is outright offensive).

Sadly until there's actual enforcement of the regulations things will stay that way.

</comment><comment><USER8> Annoying. If there is to be some legal requirement, it should be to respect some protocol that would allow you to set those cookie settings once in your browser settings.

As is, it is a complete disaster that accomplishes nothing positive.

</comment><comment><USER9> Annoying as hell</comment>


Show HN: Modd.io – Make HTML5 multiplayer games in browser - <AUTHOR> http://www.modd.io <comment><USER2> Looks cool, but from marketing point of view you'd probably convert much better if you:

\- Allow users to start creating their game without registration (lesson from early facebook games), and only after they're hooked ask them to register.

\- Be upfront about free vs paid: if it's free and you don't say anything about it, then you lose the paranoid users, and if it is paid, then you piss everybody off by asking money at late stage.

Anyway, well done and best of luck.</comment>


Tools, Tips, and Tricks to Hack Your Workflow - <AUTHOR> http://www.iamdann.com/2012/10/15/10-tools-tips-and-tricks-to-hack-your-workflow

<comment><USER2> This is a great list - thanks for sharing.

A thought: we get a lot of submissions like this (which, by and large, are all quite useful.) I wonder if there's an opportunity to consolidate (and vote/rank?) these sort of productivity/workflow/life efficiency improvers. Maybe something StackExchange-like (or Reddit-like)? Doesn't have to be super- complicated - just a list, a rank, a chance to vote, and maybe to comment.

Anyone done this yet? If not - here's an idea for someone to work on :)

<comment><USER3> Alternativeto.net is one implementation for software. For example <http://alternativeto.net/software/google-tasks/>

</comment></comment><comment><USER4> I'm not sure I understand how this hack my workflow. Some of them are neat life hack enablers, but my workflow doesn't actually depend on the weather, nor on how many emails I've send or received...

Quicksilver is the only tool on this list that seems to directly relate to workflow.

<comment><AUTHOR> I guess I use the term "workflow" more loosely than some. I consider keeping on top of my finances to be a workflow. Same with following my app sales, etc.

I agree that Dark Sky is the loosest relation, but if I know it's raining, it prevents me from doubling back to grab an umbrella, which used to happen to me all the time.

</comment></comment><comment><USER5> If the author is only using Quicksilver to find documents and launch apps, why use it at all, when you can just Cmd+Space and use Spotlight to do the same thing?

</comment><comment><USER6> Nice to see MediaWiki on here. It's such a flexible platform, you can really do a lot with it.</comment>