Slashdot Mirror

I had a lengthy conversation with netflix support, apparently, there is NO way to view 4K netflix content except for a smart TV that supports "software" as they call it. Essentially, its DRM as demanded by studio.

Is it DRM or is it just because Netflix is encoding their 4K content with H.265 (aka HEVC). There is no H.265 support in browsers and it's unlikely there ever will be due to patent licensing issues (two separate patent pools which means two separate patent licenses and there are rumours that there will be a third pool). Fortunately, the future for web video is AV1, royalty-free and aiming to be better than H.265 (see Alliance for Open Media and NetVC). In the meantime, Netflix is looking to stream 4K with VP9 so that may be an option for you soon.

BoringSSL is Google's internal fork of OpenSSL (though it's open source). It also removed all support for SSLv2 some time ago. Or, more accurately, it the SSLv2 implementation was never added to it.

https://www.imperialviolet.org/2015/10/17/boringssl.html

I think it has more to do with licensing.

Chromium is licensed under a BSD-like license. Mozilla uses the Mozilla Public License. This means you can create closed-source derivatives from Chromium, but not from Firefox, for instance.

Really? Can you link me to the the source page on AOSP where some of these spying APIs are defined?

OpenJDK is under the GPL, which means there will be a lot more GPL in Android now.

Here is the commit message. Right now they are just copying files over, so it's not entirely clear what they will be doing with the OpenJDK stuff, but it's in there. Presumably Google will modify it to use Dalvik (or whatever VM they are using now).

This is technically possible IF Apple and Google are lying about how the symmetric key itself is generated and stored.

The passcode is used to secure the "real" key, which is used for data encryption. This symmetric key is supposedly not predictable or retrievable. However, it could in fact be the output of crypt('$1$hfgfydhjd$', imei + masterkey)

That would allow anyone who knows the imei and master key to derive the symmetric key.

For Android, the code you're wondering about is all open source. Go take a look: https://android.googlesource.c...

Chrome dev doesn't autoplay videos that are in the background unless they have already been rendered once. See this commit

I'm sure if you really want to stop autoplay that you can find a userscript or extension out there or make your own that stops it on youtube (or even all websites that use html5.)
Sadly chrome devs seem to think that user configurability like Firefox has is a bad thing and so I doubt you'll ever see a default option for it.

Exodus is wrong.

The flawed patch they mention in their post isn't the one being pushed to devices. What makes this funny is that the correct patch is in AOSP, for everyone to see. What Exodus posted is the patch that jduck suggested. And it's in AOSP here. But Google further updated it with this, which fixes the flaw Exodus noticed in jduck's fix.

There are still some known ways to crash libstagefright, but they're assertion crashes. They crash safely, no possibility of exploitation.

Yep, this. Same way that you need your IE6 around in a VM so you can do your mandatory training.
Throw one of these puppies in a VM and leave a snapshot.

https://chromium.googlesource....

thanks, for those explanations. it's nice to know that custom signing keys for system images might make to nexus devices someday.
The only, sad thing is that if a device is dropped, even if it s capable of all the new and shinny things, no one would be able to bring it up to speed.
I still have that bitter after taste after support for galaxy nexus was dropped, althought it was -and still-- very much a capable device. it even had the hardware https://android.googlesource.c... /rant
again thanks for the info :)

In fact, even on Android the init system is a hobbled together "mess of bash scripts"

You think that's a bash script?

You might like to check out https://android.googlesource.com/platform/system/core/+/master/init/readme.txt

Android does not use linux's /sbin/init, or sysvinit, or OpenRC or upstart or systemd. It has its own init system which does not run shell scripts (Android doesn't even have a shell by default AFAIK).

(By the way, why all the bash love? Only an idiot would write init scripts in bash. Anyone worried about security would use a POSIX shell like dash).

In fact, even on Android the init system is a hobbled together "mess of bash scripts"

You think that's a bash script?

You might like to check out https://android.googlesource.com/platform/system/core/+/master/init/readme.txt

Android does not use linux's /sbin/init, or sysvinit, or OpenRC or upstart or systemd. It has its own init system which does not run shell scripts (Android doesn't even have a shell by default AFAIK).

(By the way, why all the bash love? Only an idiot would write init scripts in bash. Anyone worried about security would use a POSIX shell like dash).

Yes there are alternatives that are running on several hundred million linux devices. Android, for instance does not use systemd.

In fact, even on Android the init system is a hobbled together "mess of bash scripts"

One of the advantages of this 'mess of bash scripts' is that I can add simply /bin/bash -x at the beginning of the script and can have very informative messages all the way down to the kernel level. This is very useful when you need to know WHY the process doesn't start. With systemd you have no such detail, and further if your machine doesn't boot you are so out of luck trying to read those logfiles.

In fact those bash scripts are part of the software that are written in a common language, easily writable and have built in diagnostic faculties due to the fact that it is using bash. With systemd you need to invest in an entire new tool set.

The main reason that binary log files ARE A TERRIBLE IDEA is that often to diagnose the problem you have to boot from another operating system in order to fix the broken one, and that may or may not be linux. Often it can't be the same operating system by definition because it won't boot into linux because of the problem.

Seriously, working with systemd is like going back to windows where you need a special tool to even read a configuration file.

Yeah. I think Kirt's ranting about the "tyranny of Google" is BS. Although I can sort of understand where they MIGHT be coming from after the Cornerstone mess - but that was probably a no-win situation for everyone involved.

That said, I fully agree with the people that are seeing a slow move towards AOSP becoming more and more closed source. One by one, the following happens:
Google wants to integrate GMS further with a given app (no problem here)
Google forks said app to add GMS integration (no problem here, although moving it to some sort of plugin-style approach might work better as it avoids what has proven to be the inevitable result)
Google stops development on the open-source component that the GMS-integrated component was forked from within AOSP, leaving it to rot. This annoys people and is where the perception that Google is slowly "closing down" AOSP comes from.

There's also the fact that AOSP's strict scope-limiting to Nexus devices only tends to cause people to not bother upstreaming to it - https://android-review.googles... for example

Also annoying is the fact that Google still builds AOSP using prebuilt kernel images, which often depend on toolchains deleted from AOSP. Also, AOSP uses kernel headers that just happen to match the actual kernel itself in structural organization but have different names, so Bad Things happen if you try to build AOSP against actual kernel headers now:
https://github.com/omnirom/and...
and
https://github.com/omnirom/and...

while threatening to jump ship to a browser they can't even customize at all.

You can't possibly be talking about Google's browser.

Chromium is properly FOSS.

https://chromium.googlesource....

Chrome itself is closed source, but Google really does an awful lot for the FOSS community.

The browsers you truly can't customize consist of the likes of IE and Opera.

petty little complaints

I've been an open source user/abuser and proponent going on 20 years now. It's stuff like this that make me think that if you're an actual Firefox dev, you need to GTFO right now before your toxic attitude spreads.

--
BMO

Couldn't write a proper wear levelling algorithm if their life depended on it.

First the MAG4FA/KYL00M/VYL00M data corruption bug that affected the Galaxy Nexus - https://android.googlesource.c...

Then (actually BEFORE it, Google found it during Galaxy Nexus development but Samsung kept it hush-hush - but it became a public issue much later) - the infamous Samsung Superbrick fiasco (If you fired a secure erase command at the chip, it had a chance of permanently corrupting the wear leveller data to the point where the chip's onboard controller would crash until you power cycled it any time you accessed that region of flash). - https://git.kernel.org/cgit/li...

Then pre-release 840 PRO devices suffer from the SAME DAMN BUG SAMSUNG HAD BEEN AWARE OF FOR OVER A YEAR - http://www.anandtech.com/show/... - While this only affected review devices, the fact that this was a known bug since before the release of the Galaxy Nexus (a year earlier) is inexcusable.

Then there was the Galaxy S3 "Sudden Death Syndrome" issue in late 2013... - https://github.com/omnirom/and...

Then there were a few other issues - http://wiki.cyanogenmod.org/w/...

Now this...

https://chromium.googlesource....

Google supports running Chromium OS on any Chromebook. It basically has everything but a few plugins, which I believe you can install (though those are not FOSS).

I wouldn't say it is any less FOSS than something like the Linux Kernel if you don't de-blob it.

I couldn't help but think "Someone has to have tried to get this into AOSP. It seems ridiculous that they wouldn't have.

It turns out that at least some of the code was written a year ago and still hasn't been merged. If one of you Slashdotters is a gerrit reviewer, can you check out the these two requests?

I couldn't help but think "Someone has to have tried to get this into AOSP. It seems ridiculous that they wouldn't have.

It turns out that at least some of the code was written a year ago and still hasn't been merged. If one of you Slashdotters is a gerrit reviewer, can you check out the these two requests?

I couldn't help but think "Someone has to have tried to get this into AOSP. It seems ridiculous that they wouldn't have.

It turns out that at least some of the code was written a year ago and still hasn't been merged. If one of you Slashdotters is a gerrit reviewer, can you check out the these two requests?

I know everybody talks about encryption, but the word itself is just the tip of security. What's the key size? What's the algorithm?

It uses Linux dm_crypt. Here's the source code that configures it, and protects the dm_crypt master key: https://android.googlesource.c...

What data is encrpyted?

The /data partition, which holds everything which isn't part of the system image. An easy way to understand the distinction is to note that on unrooted Android devices everything but /data is mounted read-only. So any data that is stored after the device leaves the factory is in /data, and is therefore encrypted, unless it's written to removable media (SD card).

Most of the rest of your post is speculation assuming that Google is intensively mining everything backed up. I'm quite certain that's not true, but I probably shouldn't comment in more detail.

The only thing it will do is keep your private information out of the hands of someone who picked up your lost phone and decided to keep it (or sell it).

Yes, that's what device encryption is for.

(Disclaimer: I'm an Android security engineer. I'm speaking for myself, not for Google.)

Gentoo is a distribution of Linux (or GNU/Linux or whatever you want to call it) probably best known for its method of software updates where source is compiled on-the-fly to binary as part of the "portage" update system.

ChromeOS is Google's linux (kernel)-based operating system which essentially has a Chrome browser act as the entire user-facing operating system. Apps are written in HTML5/Javascript, etc.

NaCl (Native Client) is a new feature of Chrome that lets you run native (or in PNaCl, ie Portable Native Client, it's a platform-agnostic format that is quickly converted to native binary before running) code from within the browser, all in a sandboxed environment. You can actually get a shell within the browser and compile and run binary apps inside the browser as well. See the Google IO video about this.

The app code is all running on top of the Chrome platform, specifically inside of Native Client. In this way the ARC (Android Runtime for Chrome) apps run in the same environment as other apps you can download from the Chrome Web Store, even though they are written on top of standard Android APIs.

The runtime probably includes some modified version of the entire android framework, etc. meant to be wrapped up by a Chrome browser window and interact with Chrome's input/output, etc.

I don't see how this WON'T be ported quickly to Linux by someone, though it'll likely need Chrome/Chromium. Nothing has stopped Android source from being ported to regular ol' linux except that no one has done it yet. But this work by Google will probably make it easier to include in Chrome.

Incidentally, on Ubuntu, NaCl isn't compiled in, so you may want to get a version in which it is. You can turn it on by following the instructions here.

Who gives a shit what the documentation says. Actual implementation is what matters.

Absolutely. So, look at the source: https://android.googlesource.c...

That file contains the code that generates the master key, derives the key encryption key used to protect it (using scrypt), stores the protected master key, and configures dm_crypt with the master key.

Some functions to look at:

- create_encrypted_random_key(), which creates the master key (reading from /dev/urandom).
- encrypt_master_key(), which derives a KEK from your password and uses it to encrypt the master key.
- decrypt_master_key(), which does the reverse.
- create_crypto_blk_dev(), which creates dm_crypt block device.
- cryptfs_setup_volume(), which mounts an encrypted block device.
- cryptfs_enable_inplace(), which encrypts an existing file system.

Do you really trust a mobile platform to be faithful to the documentation when you're trying to wipe a partition (which could easily be implemented directly but isn't) by first encrypting all data and then throwing away the key?

The device doesn't know you're trying to wipe. It knows that you (a) requested full disk encryption and then later (b) requested a wipe. So it can't optimize (a) away. I suppose it's possible it could just lie and tell you "Yep, I'm encrypting" even though it isn't, but that's the sort of thing that would definitely get noticed by security analysts and gleefully published.

I don't think old devices are vulnerable, and while 4.3 devices are vulnerable, most of them have an additional countermeasure in place that should protect against any actual disclosure of private keys.

In older devices, it looks like prior to changing keystore to use the Binder API the bounds checking was done at a higher level in the call stack, so the code isn't actually vulnerable. When keystore's API was changed to be Binder-based, that checking was lost, enabling the bug. Looking at the git log, the Binder keystore API was merged in November 2012 which I believe means that only 4.3 devices are vulnerable. It appears the bug was identified and fixed before 4.4 was released.

But most 4.3 devices, at least from major vendors, have hardware-backed key storage. All Nexus devices do. They're vulnerable to the bug, but the private keys are completely inaccessible to the Android userspace and kernel, so there's no way the key material can be leaked. To see if your device has hardware-backed key storage go to Settings -> Security and scroll down to "Credential Storage". If it says "Storage type Hardware-backed", then keystore private keys are not accessible to the Android OS userspace or kernel, so there's no way they could leak.

One caveat: Until 4.4 (I think), only RSA keys could be managed by secure hardware. So DSA and ECDSA private keys in 4.3 device keystores could leak via this vulnerability. In the future we should have support for all sorts of keys in secure hardware (https://android-review.googlesource.com/#/c/97651/ -- yes, I'm the author of that CL), as well as a mechanism for checking the hardware vs software storage question on individual keys.

I'm not trying to say this wasn't a pretty serious error on Google's part. Even with the bounds check higher in the call stack, it should have been done in keystore as well. Security-sensitive code like this should take a belt-and-suspenders approach, not depending on validation done at other layers, specifically because stuff at other layers changes. Actually, I know the guy who wrote it and that is the way he thinks, too, so I'm somewhat surprised he wrote this bug.

(Note: I recently joined the Android security team, and it looks like I may be the maintainer of keystore. I am taking the lead on hardware-backed key storage. However, I should mention that I'm not speaking in an official capacity, just someone who knows the code a bit and took a few minutes to look through the git logs.)

I don't think old devices are vulnerable, and while 4.3 devices are vulnerable, most of them have an additional countermeasure in place that should protect against any actual disclosure of private keys.

In older devices, it looks like prior to changing keystore to use the Binder API the bounds checking was done at a higher level in the call stack, so the code isn't actually vulnerable. When keystore's API was changed to be Binder-based, that checking was lost, enabling the bug. Looking at the git log, the Binder keystore API was merged in November 2012 which I believe means that only 4.3 devices are vulnerable. It appears the bug was identified and fixed before 4.4 was released.

But most 4.3 devices, at least from major vendors, have hardware-backed key storage. All Nexus devices do. They're vulnerable to the bug, but the private keys are completely inaccessible to the Android userspace and kernel, so there's no way the key material can be leaked. To see if your device has hardware-backed key storage go to Settings -> Security and scroll down to "Credential Storage". If it says "Storage type Hardware-backed", then keystore private keys are not accessible to the Android OS userspace or kernel, so there's no way they could leak.

One caveat: Until 4.4 (I think), only RSA keys could be managed by secure hardware. So DSA and ECDSA private keys in 4.3 device keystores could leak via this vulnerability. In the future we should have support for all sorts of keys in secure hardware (https://android-review.googlesource.com/#/c/97651/ -- yes, I'm the author of that CL), as well as a mechanism for checking the hardware vs software storage question on individual keys.

I'm not trying to say this wasn't a pretty serious error on Google's part. Even with the bounds check higher in the call stack, it should have been done in keystore as well. Security-sensitive code like this should take a belt-and-suspenders approach, not depending on validation done at other layers, specifically because stuff at other layers changes. Actually, I know the guy who wrote it and that is the way he thinks, too, so I'm somewhat surprised he wrote this bug.

(Note: I recently joined the Android security team, and it looks like I may be the maintainer of keystore. I am taking the lead on hardware-backed key storage. However, I should mention that I'm not speaking in an official capacity, just someone who knows the code a bit and took a few minutes to look through the git logs.)

I can understand if Google wants to force vendors to update to the most recent android. However, from a vendor perspective, what's so hard about backporting this patch to, say, android 4.3 and below? Is there a contract with Google forbidding this? Do they get money from NSA?

Backporting it probably isn't difficult, but getting all the vendors and carriers to patch, build, validate, and deploy their custom Android builds for all the various devices they have supported over the last few years is.

I can understand if Google wants to force vendors to update to the most recent android. However, from a vendor perspective, what's so hard about backporting this patch to, say, android 4.3 and below? Is there a contract with Google forbidding this? Do they get money from NSA?

• Chromebooks are actually locked down, unlike the Surface Pro
• Google's Chromebooks actually use the same hardware, including the same WI-Fi card
• There are actually no problems with using Surface Pro 1 or 2 hardware under Linux. Everything works.

I think you mean the open source release is easy to get from Google. Which I believe was the starting place for CryogenMod.

open source android:
$ curl http://commondatastorage.googl... > ~/bin/repo
$ chmod a+x ~/bin/repo
$ mkdir dev
$ cd dev
$ repo init -u https://android.googlesource.c... -b android-4.4.2_r2
$ repo sync ... then it's the normal build steps. export TOP=$(pwd) ; source build/envsetup.sh ; ...

How about 108? https://chromium.googlesource.com/chromium/deps/nss/+/50796110f60d034dfab3d8876f62d715f31aaa9f/nss/lib/freebl/chacha20/chacha20.c

(By the way, so much for “Android does not use Java and does not care about Java compatibility”.)

https://android.googlesource.com/ and your favorite dev environment (whether that is vim and various shell tools, emacs, eclipse, netbeans, visual studio, or whatever) Is the definitive source of android documentation. But, not what you want.

If you want to see the basics of writing an android app look at the source for phonegap and titanium. Those two frameworks combined with The New Boston will allow a programmer to come up to speed quickly

But, you seem to want to through together an app that you built yourself, without having to actually learn java and such. For that Buzztouch http://www.buzztouch.com/ is a pretty good solution, and you might not need more than that, depending on what your app does.

A quick look at the android source suggests that one could disable these by changing the default return value of the switch statement in com.android.cellbroadcastreceiver.CellBroadcastAlertService.isMessageEnabledByUser() to false rather than true. There are better approaches (e.g., adding a toggle switch to the settings), but at first glance that looks like a quick and easy way to do it (assuming you're able to build and install your ROM from source code -- but this *is* Slashdot...). I guess that doesn't help if one is an iOS user, though.

If you're willing to give hints, you might as well be willing to give a few file/line pointers - even without downloading the source and Eclipse, people could look at the claimed Google's incompetence here, for example. You could also submit bug reports/patches.

As it is now it sounds like karma-whoring without anything to back your words up.

The article makes no mention of WHICH Android revision each of the given phones tested was using.

It was a known problem with Gingerbread and earlier that the wipe method used by most Android devices was insufficient. That's why Google added secure erase prior to reformat with ICS (maybe HC too, not sure...)

https://android.googlesource.com/platform/system/extras/+/c2470654d4b4db09a7052fc5fa108ac21f1b1948

Interesting result of this: Samsung's eMMC chips that were shipped in the Galaxy S II and original Galaxy Note couldn't handle this secure erase command properly, and using a standard "secure" wipe had a pretty good chance of corrupting the wear leveller so badly the chip would be rendered useless. (Samsung's own recoveries were "neutered" so as not to issue a secure erase command.)

TL;DR - Unless crippled by the manufacturer, any recent Android device (ICS or newer) should not have any of the issues with data remaining easily recoverable after a wipe described by this article. LG didn't do anything special here - they just implemented ICS or later and that's all that was needed.

https://android-review.googlesource.com/#/q/status:merged,n,z

Looks like there is a steady stream of work being done in AOSP to me.

If you think nothing happens in AOSP it's simply because you've never looked and you've accepted someone else's FUD at face value.

Also it's not about control, it's about actually getting shit done. The recent Wayland vs. Mir thing is a perfect example. Wayland was a good thing, but nobody is adopting it because the community is refusing to give up the old broken X11 for something better. And even still, Wayland has been in development for 5 years now - it's the same age as Android.

The dialer no longer allows special characters that are part or USSD codes. see patch:
https://android.googlesource.com/platform/packages/apps/Contacts/+/39948dc7e34dc2041b801058dada28fedb80c388%5E!/#F0

now, everyone can still rant about how long it will take for owners to receive an updated version of Android (if ever).

and before anyone starts the iOS vs Android bantering. No, iOS does not have this particular flaw:
"Specifically, if a URL contains the * or # characters, the Phone application does not attempt to dial the corresponding phone number."
https://developer.apple.com/library/ios/#featuredarticles/iPhoneURLScheme_Reference/Articles/PhoneLinks.html

Bullshit.

I'd say screen resolution is the /easiest/ thing to work around. With Android, you've got all sorts of problems with inconsistent behaviour between different versions. Prior to 2.3 (Gingerbread), you couldn't put assets in an APK larger than about a megabyte and the app installer won't clean up after data that you put in the officially sanctioned directory on the sd card. Trivial stuff when you're trying to bundle potentially large graphics files I guess. With Gingerbread, Google broke the Expandable ListWidget class. As far as screen resolutions go, there are predefined ways to handle the different sizes and densities. It's actually pretty flexible and one of the more intuitive things about Android development. Other than the list of acceptable values itself being something of a moving target, it's not /so/ bad.

As for the free development suite, you get what you pay for. I certainly much prefer XCode to Eclipse, to the extent that I use NetBeans to do development instead. Of course, the hot new SDK broke some minor things like incremental builds with NB. Previous versions of the Linux SDK shipped with broken versions of gcc that wouldn't compile the kernel properly (okay app devs don't worry about this, but it goes to show how chaotic the Android ecosystem is), and the supposedly supported MacOS X lacks support for various things like dexopt (OS dev) or Google TV support. Yeah, okay, I'm still chaffed that Google refuses to integrate SDK support for other free, open, non-Linux, UNIX-like operating systems and just writes sloppy code.

Linux as the required SDK platform is a bonus only if you're already using it.

Dan Morrill
  Oct 20, 4:29 am
Hi!
As you know, like many other projects the Android Open-Source Project was
affected by the recent kernel.org downtime. So, we’re pleased to let you
know that the Gingerbread source code is now available again, and AOSP git
servers are back online.
Even before the kernel.org downtime, it was clear that AOSP was sometimes
taxing kernel.org’s git infrastructure. When we did the Gingerbread source
release, for example, load due to AOSP made part of kernel.org unusable for
several days. This isn’t fair to kernel.org’s staff or the community, so for
some time we’ve been preparing our own git hosting on Google servers.
We were finishing up just as kernel.org experienced their downtime, so the
Gingerbread source is now available on Google’s servers. Accordingly, the
git URLs have changed.
Here are the instructions to access the new git servers:
      - You need to get the latest version of the repo tool:
      curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
      - You need to initialize a new repository:
      repo init -u https://android.googlesource.com/platform/manifest -b
      android-2.3.7_r1
      - The full instructions are at
      http://source.android.com/source/downloading.html
There are a few limitations to be aware of:
      - Our priority has been getting the main source code mirrors back online,
      so for the moment gitweb source browsing and Gerrit Code Review are still
      unavailable.
      - We are now working on bringing AOSP’s Gerrit Code Review site back up,
      and hope to be able to say something here soon.
      - It might be a little while longer before gitweb comes back,
      unfortunately, since Gerrit Code Review is the next priority.
      - To reiterate, these servers contain only the ‘gingerbread’ and ‘master’
      branches from the old AOSP servers. We plan to release the source for the
      recently-announced Ice Cream Sandwich soon, once it’s available on devices.
      - As these new servers are, well, new, there may be hiccups if we
      encounter unexpected issues. However we’re keeping a close eye on them and
      will respond to any issues as quickly as possible.
Finally, we’d like to send a huge “thank-you” to the kernel.org community
and Oregon State University Open-Source Lab staff. They’ve done an
incredible job hosting the AOSP source code mirror and Gerrit Code Review
for nearly 3 years. Without them, it’s safe to say that AOSP would not be
where we are today.
Thanks, and happy coding!
- Dan