Hacker News new | past | comments | ask | show | jobs | submit login
Introducing Netflix Stethoscope (netflix.com)
497 points by dustinmoris on Feb 21, 2017 | hide | past | web | favorite | 154 comments



So, 'jailed' is a reason to mark it as 'requires attention'? Well played, well played..

Honestly, I won't run a non-rooted device (although I admit that the current way to root a device is questionable in parts). But here's a real, honest question: Why would services stop working because of root access?

Why can't Android Pay work on a rooted device. Samsung's crappy equivalent (I use neither, but I think those are often considered examples for 'stops working if rooted' issues)?

I also own my credit card. Just like my mobile. What is the danger that these services try to protect against, why is root a problem in these cases?


As another reply to your post says, paraphrased, allowing applications to escalate privileges is absolutely less secure than not allowing applications to escalate privileges.

This really has nothing to do with services not working because root is enabled, instead it has everything to do with companies (Netflix in this case, or Google for Android Pay in your example) preventing widespread theft of employee/customer data.

Even the most cautious users can accidentally click "allow" by mistake. Here's a example of how that might happen:

Build an app that some user wants - maybe a game. Make the user click a "Start" button to play. Time how long between presenting the button and receiving the click, after a few rounds of this, wait a fraction of a second less than the average time and trigger the sudo call which in turn usually triggers an allow/deny popup.

Did it register with you in time, or did you click allow? Did you even notice it if the game starts anyway? Probably not! Netflix just gave an attacker an entry point, and Google just lost the confidence of their banking partners, who are likely looking for any excuse to avoid working with Google (and Apple etc) anyway.

A good IT department has to protect the company from risks like this, and nothing the company requires you to do will require root (There are obviously exceptions, but the number of employees worldwide who fit this bill, outside of phone OS development, is likely less than a 5 or 6 figure number).

If you need root for personal tasks, and the company isn't happy with root, then they are entirely within their right to deny that device access to company systems.


Listen, I'm with you. Root is special and granting root to ~stuff~ should be something you don't do on a whim.

That said: I question that services should stop working if I have the ability to grant root. Reasons:

1) Maybe I know what I'm doing (honestly .. I consider myself capable and still have cringe while writing this)

2) Your software isn't immediately compromised in its core functionality if _I_ own my _own_ device.

For Netflix, this feels like another failed attempt to close the analog hole. Android Pay and whatever else might try to be your wallet (I'm a huge fan, as you might notice in this thread) should be able to withstand that. Otherwise it's just a crappy payment system.

I can pay stuff from my PC (various operating systems) and I do have root (or the equivalent permissions). I also own - as I stated in my original post - a CC that allows me to spend money freely. I don't know how hard it would be to copy it physically, but you'd be able to strip the core details (name, number, CSC) in a couple seconds/with two pictures.

Why is the CC secure, but a rooted phone isn't. Ignore Netflix, they're brain-dead and content related DRM isn't what I'm going for. I'm asking why random legitimate services refuse to work on a phone, because .. the owner actually seems to own the device?


> failed attempt to close the analog hole

Stethoscope has nothing to do with user's of Netflix's service, and the DRM on it. This is for Netflix employees, on IT managed smartphones. This could have just as easily come from any of a number of other companies that issue phones to employees.


The only argument I would make against your points 1 & 2 is that I as a developer can't assume that a person with a rooted device knows what they are doing. For instance... I have a number of friends that have purchased rooted devices for the sake of using things like Kodi, against my advice. They do not understand their devices, or why downloading movies that hit the theater that day is illegal b/c they legally downloaded Kodi or bought a Kodi device legally. I am constantly having to fix/wipe them because they dont even understand the basics of security, ( i.e. they click ok on every popup without reading them, etc). Fortunately they pay me as I have refused for many years now to give free support, even to family. Anyhow, whenever my friends buy phones and other media devices, they almost always without fail and without asking my advice, purchase rooted ones online. Hell, for all they know, those devices could have software on them specifically for keylogging, etc.. and they would never know. So yeah, you can't assume a rooted device is in the possession of a competent user.


May have nothing to do with it but paying with CC details pretty much always has some traceable chain to the person who is gaining from the fraudulent activity. Contactless payment does not. Therefore a contactless scam could yield higher gains with lower risk than traditional cc fraud, and this poses a huge risk to any payment providers.


I'd tend to somewhat agree, but differ in what I think the big risk is - your cell phone has an internet connection, and a hacker in $foreignCountry can get to it..

The scope of risks are so significantly larger than the traditional "people who can place their hands on your wallet, or read the number while you have it in the open"...


Agreed - I said the same elsewhere on this thread


> 1) Maybe I know what I'm doing (honestly .. I consider myself capable and still have cringe while writing this)

My example kinda covers this, phones really are getting faster... It's no longer a case of "I know what I'm doing" when it now comes down to human recognition and reaction time. In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

> 2) Your software isn't immediately compromised in its core functionality if _I_ own my _own_ device.

100% agreed. For the Google Pay example, fair enough. It's your credit cards, and it's harder to come up with a counter point.. For the OP / Netfix example, it's not your data, and likely not your device - or - by connecting to company services, you've basically agreed it's not yours (This could be a whole sidetrack on it's own! :))

> Android Pay and whatever else might try to be your wallet (I'm a huge fan, as you might notice in this thread) should be able to withstand that. Otherwise it's just a crappy payment system.

Credit card companies are generally responsible for theft of money where you remained in possession of your card at all times. Sure, they really hate admitting it, and gathering the proof is hard, many times impossible. But that doesn't change the responsible party when the proof is found.. Given this, it's easier for them to accept less secure alternatives (e.g. the US's reliance on signatures).

The rise of NFC credit cards has changed this somewhat, if a credit card hands out all the details needed to make a purchase to anyone who bumps into you on the street, possession is now not the only factor, and banks have built safeguards around this (e.g. max transaction size, max NFC transactions before being required to enter your PIN).

Google with Android Pay must prevent that same bump on the street from stealing their customers money. The cell phone payment version of this comes in the form of other apps on the device, hackers breaking into the phone remotely, etc. With a rooted device, or a device using unknown firmware[1], all bets are off.

> I can pay stuff from my PC (various operating systems) and I do have root (or the equivalent permissions).

And this is a security hole, granted it's one I wouldn't want to see shutdown, but it's still security hole. I don't have any good answers here, but I do look forward to seeing a solution that works while letting me keep root access on my Linux box!

> Why is the CC secure, but a rooted phone isn't.

I'm think I've mostly covered this, but you're looking at two totally different landscapes. They just cant be compared in the same way.

> Ignore Netflix, they're brain-dead and content related DRM isn't what I'm going for.

While I'm no DRM fan, this entire article is about Netflix's corporate employee device security, it's nothing to do with DRM or content..

[1]: Unknown firmware in this case means firmware google doesn't trust - unrooted AOSP built from a unknown manufacturer can't be trusted any more than rooted firmware from Google itself.


> My example kinda covers this, phones really are getting faster... It's no longer a case of "I know what I'm doing" when it now comes down to human recognition and reaction time. In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

If this really is a problem, the OS could pop up a question such as "This app is requesting escalated privileges", and then wait ten seconds before popping up the allow/deny buttons so the user doesn't click blindly.


> In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

The simple solution to this specifically (which I think has been implemented already anyway for some Android rooting options?) is to have a few seconds of delay where the "Allow" button on the root permission request is greyed out.


I can no longer reply any deeper on this thread, must have tripped a reply limit :) Time for bed right after this!

Re adding a delay to counter this, see my other reply here https://news.ycombinator.com/item?id=13701227 - a delay isn't enough..


> In other words, you clicked allow before your brain had time to stop you. How do you prevent this?

The best SU apps have a timeout on the popup specifically to prevent this. I specifically use phh superuser (or, rather, MagiskSU) which has a 2 or 3 second timer from when the popup shows up till you can press accept.


I don't see how protection from hostile NFC and protection from rogue applications are related. You want both, ideally, but the increased difficulty of solving problem 1 on a phone vs. desktop does not make it harder to solve problem 2 on a phone vs. desktop. So I think you're wrong to say that it's "two totally different landscapes".


Ah, I was suggesting that comparing "I have a CC in my wallet and can do stupid things with it" to "I have a CC on my phone now others (hackers, bad apps) do can evil things with it" are two totally different things.

I was drawing parallels between hostile NFC readers and hostile apps/hackers :)


But the more important comparison in those posts is not CC in wallet. It's that CC on desktop computer has no restrictions.

"hackers/hostile apps can do evil things on desktop" is nearly identical to "hackers/hostile apps can do evil things on phone"

So while in a vacuum you could argue that you need to protect against hostile apps the same way you protect against hostile NFC, it's a weak comparison. While the treatment of hostile apps on your heavier home computing device is a super strong comparison.


I'm not sure I agree it's a weak comparison, mostly because I think we've made a whole bunch of bad decisions in how we handle things on a PC.. The PC was born in a different era to the smartphone, and it's treated as such.

Example: CVV numbers, these are needed for "Card not present" transactions are must not be saved (e.g. no browser will save them). Using your phone for an NFC payment on the other hand does not need this number.

Yes, this is a tiny detail. But this detail entirely changes the share of responsibility between the consumer/merchant/payment processor/bank.. This is usually reflected in the different fees that are charged for different types of transactions, card swipe vs card not present vs Chip+PIN vs NFC.

Assuming that just because a CC number + errata stored on a PC can be stolen an abused, that the banks etc should just let me do that on e.g. Android Pay is just wrong..

Nobody is stopping you from creating a text file on your phone with the card and CVV numbers, but don't expect to be able to use that text file as a NFC payment method!

Edit: in case I wasn't clear (I know I wasn't, because I kinda forgot to say it ;)), once your phone is untrusted - as in untrusted by the bank etc - everything stored on it may as well be that plain text file as far as they are concerned.


>Build an app that some user wants - maybe a game. Make the user click a "Start" button to play. Time how long between presenting the button and receiving the click, after a few rounds of this, wait a fraction of a second less than the average time and trigger the sudo call which in turn usually triggers an allow/deny popup.

I would consider this a software fault. Your SuperSU-or-equivalent app should do something similar to what Firefox does for downloads (the button is greyed out for a few seconds before you can click it).


Absolutely, 100% agree. I'd go further, and require a password or pin too.

But - they don't currently do this, and there's no way that I can think of to reliably, as a third party, validate SuperSU etc is actually doing this.

EDIT: Also, some users really are.. ill informed and gullible. I hate saying it, but a large number of employees even at a tech company will click accept after a quick popup that says "For best 3D performance, we need root access to use your phones graphics chip directly".


My main reason, or probably only reason to root my devices is to populate the hosts file with anti-advertising entries. Which may be safer than a device that is exposed to all the advertising crap.


You can do this with an on-device VPN, which doesn't require root: https://github.com/M66B/NetGuard/blob/master/ADBLOCKING.md

The app is also on the Play Store, but the adblocking features are only in the Github version (presumably Google will not approve this functionality for Play Store apps).


And this is one of the few reasons I envy iOS users, Apple shipped ad-blocking APIs of some kind (or did that actually come out yet/ever?)

Google will likely never do this :(


Services like Android Pay quite reasonably elect to not work if the device appears like it may have been compromised. It's not easy to tell if a device is rooted because the user wanted root access or because a virus got in.

But suppose you established that the user intentionally rooted the phone (somehow). It'd still not be clear whether the rootkit that the user used was trustworthy. Even if you established that it was trustworthy (stretching the bounds of reasonableness; who is auditing these?), you couldn't assume that the user hadn't run other malicious programs. That last point is true for non-rooted phones, of course, but since this user had root access those hypothesized malicious programs become much more dangerous.

(Also, I doubt you own or have root access to your credit card. But what would you do with it if you did? All I can come up with is to consolidate a few of them onto one piece of plastic.)


Re: Credit card: I own one, I can hand it out. Most of the information necessary to use it (name, number, CSC) are available if you hold that card for a second.

My (honest, I'm not trying to pull your leg or anything) question is:

I have a phone. I own it. You (payment provider) cannot control it and I might do stupid things.

I have a credit card. I own it. You (card issuer) cannot control it and I might do stupid things.

Where's the difference? How can CCs work, but Android Pay/Samsung WhateverWhyWouldIUseIt doesn't, given my current impressions above. Can you correct my errors?


Credit cards don't have radios in them with 24/7 internet connections and software vulnerabilities.

I think it is reasonable to assume, as mentioned elsewhere, that rooted devices are more prone to data-compromising attacks. And, due to security bugs, devices that are rooted may not have been rooted with the owners knowledge or permission.


It's a lot harder to attack at scale when targeting credit cards than an attack that targets mobile devices.


The difference is, you don't actually own your CC. You have physical possession yes, you can manage various aspects of it yes, you can even turn it off if you desire - but you don't own it. The bank does. The bank controls the card far more thoroughly than you do, including rights to create, replace, remotely destroy, cancel transactions, etc. You have the physical card and you can use it, but all of the permissions you have are rights granted to you by the true owner of the card - the bank.


its actually against the banks ToS to give your credit card to anyone else... even at the register.

but everyone ignores that :-P


It's easy: just ask the user.


As if the user knows if they've been rooted by a malicious third party.


Rooting can allow software to elevate privileges enough so it can see outside its sandbox and access other software's private storage.

That means (for example) spyware has one less thing stopping it form manipulating (eg) Android Pay to steal money.


>So, 'jailed' is a reason to mark it as 'requires attention'? Well played, well played..

I must be reading the image wrong. Jailed has a green check mark beside it, and Up-to-date has a red negative sign. Presumably, this is why the device would require attention?


You don't own Netflix content. You pay for temporary access to it. If you could use root access to compromise the app and pirate their content, that could cost them licensing deals and lots of money. If you can't use root, that costs them little.

You don't own your credit card either. The piece of plastic is actually owned by the bank. As they will likely be the ones that take a loss in the event of fraud from malware breaking into Android Pay, but similarly they gain nothing from letting you root your device, so their behavior makes sense.


It's the usual security theater. Custom roms do a good job of securing root access for apps, what I find hilarious is a sideloaded app can do a lot more damage yet Android Pay works if you have sideloading enabled... go figure.

You can get Android Pay to work on a rooted device using systemless Xposed framework and root cloak, it basically just lies to the dumb checks.


A side-loaded app cannot access another app's storage.


But if you have root, then why would any software you don't want to know you have root, know you have root? That is, if you control the device, have it lie about the control you have to things that care...


But you don't own your CC if you read the back it normally says "property of (whatever bank)"


> So, 'jailed' is a reason to mark it as 'requires attention'? Well played, well played..

Yeah, that's pretty dumb security theatre. If the device is rooted, it can fake your root checks. Just ask Blizzard.

Better to figure out how to operate even when that happens.


>If the device is rooted, it can fake your root checks. Just ask Blizzard

What happened with Blizzard and rooting?


Blizzard is continuously playing cat and mouse games to see if you are using bots or cheats for their games. Blizzard comes up with a bunch of anti-cheating checks and within days they all get defeated.

It's a never-ending task.


If anyone from Netflix reads this can you fix pinch to zoom on iOS on your blog please? I kept trying to read the article, but the text is small and every time I tried to make it bigger the swipe to navigate articles gesture was triggered. Not very accessibility friendly.


Same here. Only way I could read this on mobile was using iOS Safari's text formatter thing that shows up in the URL bar.


This is related to employees only right? I would have thought a large company like Netflix is using something like G Suite and therefore can just use Google Apps Device Policy to simply enforce the best security settings (6 digit code, software updates and so on) on Android devices. And I bet there is something comparable for iOS devices isn't it?

https://play.google.com/store/apps/details?id=com.google.and...


While this is related to employees, it seems to be focused on other devices which are not under any group/device policy.

> By providing personalized, actionable information–and not relying on automatic enforcement–Stethoscope respects people's time, attention, and autonomy, while improving our company’s security outcomes.


I'm wondering how they plan on rolling this out, do they just send a company wide email asking everyone to download the app? As an employee if I refuse or ignore the directive am i subject to disciplinary action?


I have to admit, the screenshot they picked seems like a really bad example :)

Most Android devices can't just be updated to the latest version, which is counter to the proposed goal of being user actionable.. Won't this particular check just result in alert fatigue? Once any single alert comes in that the user has no control over, they HAVE to ignore it, and once they ignore one, it's easier to choose to ignore more..


There was a startup that addressed this issue of personal devices potentially leaking personal or business sensitive information. The idea was the device is protected all the time, not just while on the office network.

They were Mojave Networks but looks like their website is no more. Acquired by Sophos... I guess their called Cloud Web Gateway now. See links.

https://www.crunchbase.com/organization/mojave-networks https://www.sophos.com/en-us/press-office/press-releases/201... https://www.sophos.com/en-us/products/cloud-web-gateway.aspx


Mojave was a great idea. I've tried and failed to recruit the founder and engineering leader for Mojave at least three times. :-)


How do you detect whether a device is Jailbroken/rooted ?

[Edit] : Found this - https://github.com/scottyab/rootbeer

I think this will be useful for applications that want to know if the execution environment is safe or not - Banking / Payments etc.


In Android, you can use the Google SafetyNet API, that checks whether the system partition has been modified or mounted r/w, the existence of the su binary and some more clues like those.

I don't know the current state of jailbreak detection in iOS, but I do remember that some time ago, as a rudimentary jailbreak detection, iBooks tried to run unsigned code at launch, and if it ran, the app would refuse to open.


Interesting, I am guessing there is some kind of learning net behind SafetyNet API - Harvesting all the device infos.


SafetyNet is pretty flexible. It actually isn't implemented inside any APK - "The SafetyNet service reaches out to a Google server and downloads a binary package with the code. It goes to great lengths to validate the integrity of the package, for example using hardcoded certificates (pinning). This binary package is essentially a JAR file that contains a classes.dex file with java bytecode. Play Services caches it in dalvik-cache (snet.dex) and loads it dynamically using reflection." [1].

I think right now the only way "around" it has been Magisk [2].

[1] https://koz.io/inside-safetynet/

[2] https://forum.xda-developers.com/apps/magisk/official-magisk...


And suhide [1], but that one's a cat and mouse game, as acknowledged by the developer.

[1]: https://forum.xda-developers.com/apps/supersu/suhide-t345039...


I don't think that'd be necessary. Google's stated that SafetyNet's purpose is not excluding power-users, but ensuring the security model of the OS has not been compromised, in order to activate certain sensitive functions (e.g. Android Pay).

Given that developments in the root community are few but well-known, it'd only take a weekly visit to the XDA Developers forum by an intern to learn about any new rooting method, and not many resources to successfully block them.

No need for a complicated (and expensive) information gathering and mining rig _for SafetyNet_. Could they be gathering that information with other purposes? Given that Play Services de-facto has root powers within Android, maybe.


You can try lots of things, detecting su binaries, UI applications, checksumming the entire filesystem, etc. But ultimately if the user doesn't want you to know, you won't know.

Rooting or jail breaking your device is taking control of your device into your own hands, if you use something like Magisk, you can fully bypass root detection, even via the nastiest methods on Android.

Detecting it as a security problem is moronic. In fact, I'd argue it's actually a security improvement due to things like XPrivacy.


> Detecting it as a security problem is moronic. In fact, I'd argue it's actually a security improvement

By definition a jailbroken device is vulnerable to something as that is how it was jailbroken in the first place. Having the most up to date version is usually the safest thing for a user.


Sure, so detect that as the problem.

That's not true of rooted Android devices though, most Android devices allow you to enable a developer mode which will allow you to replace the ROM entirely if you like with no need to exploit anything.


I think your talking about bootloader unlocking rather than dev mode


I'm curious to hear other people's opinions about this. I feel like the smartphone security model provides security for the OS developers, the app developers and their advertising customers at the expense of usability for the users. But it also provides real security to the users.

I generally choose usability over security, but maybe I should be more paranoid.

I do not have android pay enabled on my phone but I'm not sure I'd be comfortable with it even if I wasn't rooted. I insist on root because I want to block ads and install themes. It's possible to do these things without root, but it's harder.

Please comment people with deeper knowledge of security.


The sandbox has been good in that it hasn't let the Windows model of apps running rampant with admin privileges do whatever they want with your data. It's mostly prevented cross-app data access.

But that's not where it stops. You see, there's still plenty of great data they can grab when you blindly click accept on that permissions dialog. Contacts are grabbed by many applications, unique device identifiers, loading your app with ads, even grabbing GPS location are pretty much standard practice now.

These practices which used to be labeled spyware or adware and hunted down and removed are now the norm.

These apps grab this data and then throw it out onto the open internet, often over unencrypted connections to parties who you don't know or trust, who are often unrelated to the app developer almost entirely, most often just so some advertiser knows you play a certain game or live in a certain city.

It depends on your definition of security - if it's strictly clicking on an ad and getting malware - it's great - but if it includes things like leaking contacts, locations and identifying information - it's terrible. XPrivacy is the only solution I've seen to really hit back at it.

Rooting your device does NOT immediately lose all sandbox benefits. It only selectively bypasses it. If you don't approve EvilMalware to bypass the sandbox - it still can't break out.

As for Android Pay? Go ahead and use it. Rooted or not, to my understanding, you're not liable for fraud on it, your credit card company will still reverse transactions no problem.


Interestingly, it's how Pokemon Go detects whether or not you're trying to 'cheat' the game, and flat-out refuses to run the game if you're in either a rooted OS or are running anything non-vanilla (I lost access to the game after they decided to block cyanogenmod in the same update).


Yeah, so it depends on the way they detect it. You can bypass anything, even Google SafetyNet with stock ROM + magisk + systemless Xposed + phh su and using Magisk Hide if you're determined enough.

CM ships pre-rooted - you just enable it in the settings, but the su binary is present and can be detected by any app looking for it. So that's a very common way to detect it on CM.


I did all this and still failed the SafetyNet check on a Motorola X Style.


It seems things have shifted again since I last checked and now magisk has its own builtin su, magiskhide is greatly improved and many people are using suhide instead altogether.


> Detecting it as a security problem is moronic

That's an interesting stance, you don't care about rootkits? What about malware, which has been found in the wild, which abuses root privileges to steal account information? That malware is extremely difficult to detect directly.


On Android, the standard root system most people apply to their device prompts you when you launch an application if you want to allow it root access. This makes it trivial to block malicious applications - that new game you downloaded probably doesn't need root for any good reason. Just hit deny. The sandbox is still fully in place, just now you can poke holes in it for certain applications of your choosing.

What you're thinking of are things which use exploits to gain root - this may be done by some users, but most often Android devices are rooted via bootloader unlocking these days, which does _not_ use an exploit.

Exploits however are used by malware - and not having your device rooted won't prevent them. They gain root via exploitation, whether you want them to or not.

Not to mention that the kind of root detection done is by looking for things that only the legitimate sort of root leaves behind, like a su binary which prompts the user if they want to permit root or not.

Often times, rooting your device legitimately may allow you to flash a custom ROM and get updates that your original vendor hasn't released for your device, allowing you to actually _prevent_ exploitation by malware, even after your vendor has long abandoned the device.


My experience has been that Android malware authors tend to be kind of sloppy, and frequently leave a modified su binary hanging around. YMMV.


In the same place that you'd install it as a user?

That'd be some very stupid malware - anyone who was actually rooted would notice immediately when their root tool told them their support binary needs to be updated.


Presumably you use something to manage which apps get root access. Or is there actually malware that doesn't require any user screw ups?


Depends on the method of rooting


For instance, if you get a malicious application which roots your phone and doesn't bother to tell you (the nerve!). You might have a security problem with your phone whose most easily detectable sign is the presence of root.


Not moronic. If your front door is open, how do I know who opened the door?


"I think this will be useful for applications that want to know if the execution environment is safe or not - Banking / Payments etc."

Which is the safe one ? The default ecosystem or the jailbroken one ?

I ask because most of the advanced security measures and hardening that I ever considered doing on an android phone required jailbreaking ...


Nothing is safe. The platforms can atleast do a better job to provide feedback or display on the UI, whether the current environment is safe, for monetary txns etc.

Secureboot [0] creates trust between hardware and software, but here you have to trust the hardware. An interesting question is how can software audit its hardware that is driving it ?

ARM TrustZone [1] is another way to offload all the sensitive computation onto another embedded SoC. But, its hard to know what the application is using. You sort of have to trust the banks to do the best job.

[0] https://source.android.com/security/verifiedboot/

[1] https://www.arm.com/products/security-on-arm/trustzone


My first guess would be to attempt an operation that only works if the device is rooted.


One thing I used to do was check if the hosts file had been modified, or something like that.

I had conditional paths for showing ads, and some rooted phones had blocked ads based on IP address.


Try executing something that needs root-level access(?)


Really glad they're thinking about osquery support in the future. Of the data sources they support, osquery would be the most functional free and open-source one which might help get Stethoscope more widely deployed.


My current policy is to keep work and personal devices completely separate. Call if you need me urgently, otherwise it can wait until the next work day.

I used to have my work email and Slack on my phone. Eventually we started to implement stricter security, which I found disagreeable, so I purged everything work-related.


The page is down for me as of 13:20 EST.

Cached version:

    http://webcache.googleusercontent.com/search?q=cache:xcxywckCegkJ:techblog.netflix.com/2017/02/introducing-netflix-stethoscope.html+&cd=1&hl=en&ct=clnk&gl=us


Are you trying https instead of http? It's only hosted on http (because they use Google Blogger with a custom domain name)


I had the same problem, and it does indeed to be caused by the extension HTTPS Everywhere that I imagine a lot of HNers use.


I'm not using the extension, it is the remote server that is redirecting to https, not the local browser.


Is there a place one can actually use this tool? My daughter uses my account, and I'd actually like to see the results of her setup.


I believe this is tailored towards employees rather than end-users


I haven't tried it myself but it appears as if you can get this up and running on your own collection of devices assuming you can all get them managed under the built-in google device management or using JAMF for iOS. It's nothing really related to Netflix other than that they are using this on their corporate-owned devices to make sure everything is secure. I guess this is simply just a nice way to combine a bunch of different data sources from mobile device management services (android, ios, windows, etc) into a single dashboard. I don't really run enough things that would require something like this but I can definitely see this helping businesses that want to do MDM.


> Stethoscope is powered by a Python backend and a React front end. The web application doesn’t have its own data store, but directly queries various data sources for device information, then merges that data for display.

I thought the "various data sources" scenario was exactly what Falcor was for - interesting that they used React.


React is a UI library and Falcor is a library for data fetching. They solve different problems


Yes, you're totally right, I should have remembered that.


We also want people to be comfortable making these changes themselves, on their own time, without having to go to the help desk.

The part of that that I don't agree with, is "on their own time". What if the change that needs to be made an urgent security fix?


It means that you don't have to bother with IT if you want to install an App, for example.

Many company provided phones are locked down completely, you can't install or upgrade anything yourself.


That logo reminded me of those rubber toys for babies : http://www.sophielagirafe.fr/en/

This is so close, it has to be intentional !


Sophie never had that creepy smile!


Very interesting tool. Tried to build something like this awhile ago but it became a bit messy. Glad to see Netflix have done it. I can see myself using this for a number of groups we work with.


Isn't Netflix motivated to see if you changed your network (such as using a VPM)? I don't see why this wouldn't call home and report you


Is anybody else using firefox having crashes caused by this webpage?


How would this protect against phishing?


It's not super clear from the writeup, but a big part of it is providing security notifications to users. So when a backend system detects what looks like a suspicious account access, it can notify the user and ask them to confirm their action. If they say, "I didn't do this" than their account can be immediately locked down until the issue is resolved by talking to a person.


"Give us data."


Wow that site hijacks the edge swipe to go to another blog post instead of letting the browser go back. Gross.


That's because it is, for some reason, hosted on Blogger (which even Google themselves have abandoned for their corporate blog).


I'll be glad to see Blogger die. Such terrible UX.

Still today, its editing interface is awful and reminiscent of the early 2000s WYSIWYG editors.

Still today, some Blogger blogs I visit (including one of my own old ones) simply DO NOT LOAD, they are stuck at an infinite loading Javascript spinner.

Even still today, it insists on serving me all its content in the language of the country I'm currently visiting, even though I have my language set to en-us in my Google account and on my browser and I consistently change its language settings back to English.


Their new entirely-JS based layout only happened after Google bought them.

Before that, Blogger's sites were completely degradable and perfectly functional without Javascript enabled. Then Google decided to remake all the templates to be fully JS driven and added a ton of page weight to the site.


So what does google use for corporate blogs, then?


Imgur does that as well on mobile. It's a terrible design because I'm scrolling down sometimes and it switches images instead. Not a big fan!


The bigger problem is that your browser let it without your permission.


What OS/browser are you running? iOS 10.2.1 with safari seems to work as expected for me.


Lol looks liek some bootstrap CRUD crap. People are getting 375k for this?


[flagged]


We detached this subthread from https://news.ycombinator.com/item?id=13699542 and marked it off-topic.


I'm sure there is a way to rephrase this to bring some valuable input to the discussion rather than just patronizing the parent comment.


You obviously never commented. /s (sarcasm don't kill me)


not installing corporate spyware on my personal phone thx bai


>7 admirer married

>7 admires sidearm

"That's an awful purty wife you got there; shame if something happened to you"


This was probably supposed to be a comment on the Anagram article: https://news.ycombinator.com/item?id=13696196


I deleted Netflix from my phone when the lastst update demanded access to my media files and photos, microphone, and call information.


It doesn't demand it, and in fact those are just basic defaults when using the new permission model/build APIs, though they default to off. In my 7.1.1 permissions Netflix lists those three, and none of them are granted nor have they ever been requested by the app.


They were presented when I tried to install the lastest update, and there was no option other than "Accept".

They don't need that stuff so I deleted the app.


That's fair, but it sounds like you're running an older Android version? In this case, your blame should lie with Google's old permissions model being not-fined-grained enough rather than at anger with Netflix over the permissions. Given the constraints on making the app, in order to satisfy you (no new permissions) they would have to halt feature development for things that customers demand, like offline play.

You can upgrade your Android version possibly, to find that the Netflix app will not require those permissions if you install it.


You are not on Android 7 yet. Prior to "Nougat" the fine grain permissions control was not available so permissions were an all or nothing thing at install time. Starting with version 7 you only enable a specific permission the first time the application needs it. And you can change them later if you wish on the permissions section of the application in app manager.

https://goo.gl/photos/2rvYmX6WNgGVfEsJ7


You're off by one version: it was Android 6 (Marshmallow) that introduced the fine grained permissions.


I stand corrected.


I believe it want's access to media files and photos to allow the newer download for offline playback functionality.


Access to storage is probably because offline play requires that permission.


IIRC, call information can be explained by the app wanting to be able to auto-pause playback when you get a call. Not sure about the others.


Microphone appears to be used for (upcoming) voice search functionality and an upcoming feature where people will be able to voice call customer support from within the app. Access to media is for the new download and offline viewing function.


"As we say in the Netflix Culture Deck, responsible people thrive on freedom, and are worthy of freedom."

But you arbitrarily can't watch stuff in Incognito Mode?


Can't have people watching two streams on the same computer. Common sense or something.


Interesting. Trying to find some sort of correlation between this and the core business of Netflix. Not sure they relate with each other. What does that means? Netflix devs are "tired" hehe. :)


Aside, I've been looking into writing some basic browser extensions for Netflix, like allowing a hotkey to toggle between English <-> Spanish subtitles so I could quickly lookup words I don't know. Or increase playback to 1.25x speed since I primarily use Netflix for language learning.

But I've been having a hard time figuring it out. Inspect the playback bar to see what I'm talking about. Anyone have any luck extending the playback UI or hooking into it?


How do you use Netflix for language learning? I'm curious.


Watch content in the language you are learning. Its pretty helpful if you are not surrounded by native speakers. I think most of my friends who grew up in Asia all watched Friends.


I watch shows with Spanish dubs + Spanish subs. Since they are translations, the language is simplified.

At first it was super slow. I paused almost every frame to look up words or phrases with google translate. If I still can't divine the phrase, I switch the the English subs for that frame.

Over time I just got better. Now I can watch shows without much pausing or word lookups.

I can read Spanish fairly well these days. Unfortunately, it didn't seem to work out my hearing/speaking muscles at all and I have to train those independently.

The upside is that I can netflix & chill with a Spanish speaker.

The catch is that this isn't a good strategy for shows that you particularly want to enjoy. Translations lose pretty much all the character, becomes robotic, and the characters are spread between the same 2-3 voice actors.


It helps a lot with understanding spoken language in a variety of settings, pronunciation, idioms, and all the other little things that make language appear natural. Watching movies and TV shows in a foreign language that you already know somewhat but aren't comfortable with yet is tremendously helpful, and it's also fun. Great way to help become fluent.


Even if you barely know the language, I've found it beneficial to listen to foreign language audio with subtitles (YMMV). It mean that when I actually try to learn parts of the language, I already have somewhat of a feel for it, so what I'm learning solidifies into something usable more quickly, and I don't spend as much time stumbling with pronunciations/verb conjugations etc.


My problem with foreign audio + English subtitles (if that's what you meant) is that my brain just reads the subtitles and tunes out the audio for the most part.

I think anything is better than nothing, though. I personally watch movies/shows now always with foreign subtitles.


I hate subtitles that aren't in the same language as the audio, that's just incredibly confusing. Having both in the foreign language requires a higher level of proficiency, sure, but I find it a lot more rewarding.


I would imagine it would help a lot with learning cultural idioms as well. Given that a large percentage of the mannerisms my friends and I use are copied from TV, it would be invaluable to be exposed to the language elements which speakers of that language actually use.


Although the focus is mainly on the Stethoscope security feature and what it has to offer, but does anyone else find the giraffe with the stethoscope a bit odd, creepy and out of place?

I think they were going for a "friendly" approach but it just doesn't do it for me. Now, you may argue that the logo isn't important but some users will utilize a tool purely based on aesthetics...why a creepy giraffe? Am I missing something in American pop culture..? (I'm Canadian...)


https://en.m.wikipedia.org/wiki/Uncanny_valley

This explains some of what you are describing


Thanks for the link! I've actually never thought about this concept and it actually does describe a bit the way I feel about the giraffe.

The designer did a great job drawing it...but something just doesn't feel right...


The giraffe feels like it's asking you to lie down on the table and relax, in the same way that Hannibal Lecter might.


Uncanny valley refers to near life like looking humans, not animated anthromorhised animals that don't look like the real thing at all


You're right, the giraffe looks odd and creepy. They should change its facial expression to be a bit more neutral.


I think it's at least partly the grin - I assume they were aiming for friendly/welcoming, but to me it looks like it is about to start nodding to itself before doing something unpleasant to someone.

Toned back slightly, I'd probably have not noticed it.


Its the Giraffe from Madagascar.

Maybe.


That's what I thought as well!

Melman.


Wow. "Jailed" is a compliment, now. You shouldn't own your devices, it's a security risk. Please keep your phones nice and safe and locked-down in our hands.

Totally backwards. As Mr Trump would put it, SAD!


This is focused toward companies to ensure employee security. It's no secret that jailbroken phones are less secure, and if an employer is giving phones to employees for work use, it's perfectly reasonable for them to enforce a rule that phones are not jailbroken or out of date.


> It's no secret that jailbroken phones are less secure

There is no evidence that jailbroken or rooted users have resulted in any significant compromises.

At least in the Android world, you must still approve any application which wants root access and rooting your phone allow you to gain access to some pretty impressive security tools you otherwise wouldn't have available to you. Generally speaking, users who are rooted or jailbroken are sophisticated enough to handle this on their own - and often use it to improve their security, not damage it.


If you are using the phone for work, you shouldn't be opening up access to a local admin account. Rooting/jailbreaking is a double edged sword. You get more control over the device but you also open up access to malicious applications. Just because you may be smart enough to run a rooted phone without compromising it, doesn't mean everyone else is capable. Keeping the phone locked down can greatly help prevent intrusions and otherwise unwanted code from running. You can do a lot more damage as root than you can as a user.

You were given that device to do work on, not take apart and do whatever you wish with it. If you want your own dev device, buy your own phone. I see plenty of coworkers who carry around two devices each day.

Companies that lock down the employee computers to only allow whitelisted applications to run deal with a lot less reimaging and malware cleaning that those that give local admin access to the employee. It does result in employees having to request installation of things outside the standard core software but it still takes less time than dealing with typical malware.


> If you are using the phone for work, you shouldn't be opening up access to a local admin account. Rooting/jailbreaking is a double edged sword. You get more control over the device but you also open up access to malicious applications.

It only "opens up access" to applications I allow explicitly. And I run things like XPrivacy which allow me to hook privacy compromising applications.

In reality it's much better for security to be rooted if you know what you're doing.

It's only a problem if you're allowing root for say, random games you download... and I don't think many people are doing that. Generally if you're rooted or jailbroken, you know what you're doing.


> if you know what you're doing

And if you don't, it's potentially much worse security. If your device is rooted, that's an attack vector that didn't previously exist. Since this tool is about informing and not enforcing, then if you really do know what you're doing then you can choose to take no action. If, however, you're not aware of the risks rooting a device exposes you too, then the tool provides an opportunity to learn that.

Further, this tool wasn't made with protecting an individual so much as protecting an organization. Yeah, you know what you're doing, but are you willing to bet your organization's security on that being true for everyone now and in the future? One compromised device can be all it takes for an attacker to get in. Not everyone who roots really knows what they're doing, it's very easy to root some phones, a quick download on a PC, run an app, click a button, and tada! Also, what about the non-techie person that asks their tech-savvy friend to root because they want to be able to <any single one of the things rooting allows>? Do you trust the judgement of every person tech-savvy enough to do this to never root another's phone without them really understanding the consequences?

</rambling>


Rooting a device doesn't immediately expose you to risk, you must manually allow that. There's very little malware around if you stick to the standard app stores like most users will too. Ads that push malware - a major problem on Windows - practically don't exist on mobile because the impact would be so small. Especially if they're trying to target only rooted users.

Phones don't seem to be very popular attack vectors and many main attack methods could be performed without the need to root the device at all.

All in all, I'd be very surprised if rooting a device ever resulted in a significant compromise which couldn't have been done without root. Exploitation excluded obviously.


FWIW, jails have been a compliment in this context since the turn of the century: https://en.wikipedia.org/wiki/FreeBSD_jail

It's not what's being referred to here, but there's no weirdness in the language.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: