Twitter Thread Compiler Apps and Copyright Ethics - <AUTHOR> http://www.erynnbrook.com/when-twitter-threads-fly-away/ <comment><USER2> > _But I can't support any product that aggregates content for profit and > isn't built from the principle of compensating and protecting content > creators from the get-go_

This is literally what twitter is.

> _No, I don't like screenshots of my threads being reposted on Facebook or > Tumblr. I don't like my tweets appearing in ad-filled listicles that someone > got paid to write._

If you're going to speak publicly, and say something that attracts interest, this is inevitable. As shitty as "twitter journalism" is, at least they're providing correct attribution to the original author. This is how online discussions work, and I think that a rule that says you're not allowed to quote other people would be harmful to society.

<comment><USER3> > This is literally what twitter is.

Perhaps technically, but I think by "aggregate" she means by crawling, rather than places where people post themselves.

> I think that a rule that says you're not allowed to quote other people would > be harmful to society.

Actual journalism, which just quotes parts or mentions the content in order to comment upon it (like you did), is very different from what she's criticizing, which is wholesale copying without any further purpose.

<comment><USER4> I'm not sure it's fair to say 'without any further purpose'. People aren't leveraging the functionality of a third party to show a thread of tweets for fun; they're doing this because the experience of reading a thread on Twitter isn't as good as it could be, and the (what feels like a) sudden proliferation of thread compilers is a testament to that. There's a definite value add I think, and while she may not like it, I don't see that going away anytime soon.

</comment></comment></comment><comment><USER5> > But imagine what she'd have if her name was attached to every instance of > the image, doctored or not?

Of course that's one of the first edits that will be made: removing the credits. Especially when they're placed unobtrusively like in the example.

I do want to note something, though: the author uses some loose wording when mentioning the change to "copyright" the example image, but that's a little misleading: it was copyrighted the moment it was made, even without having the notice. A notice can still be a good idea for various reasons but I wouldn't be _too_ worried about it, honestly.

Actually exercising your rights could be a fraught process for all sorts of reasons but you do have the option.

</comment><comment><USER6> I understand where the author is coming from; people absolutely should be paid for their labors and if other people are making money off of that, the first person should share in that. Plus, there's definitely a desire for a creator-- of any stripe--to want to have their creation viewed in the way that they originally created it.

On the other hand, and maybe this misses the point entirely, I absolutely loathe Twitter threads. I wish every time someone felt compelled to write "Here's a deep and insightful look at that thing you read me to find out about. /thread," the word "thread" would be replaced with a link to a long form post even if it had the same words. Part of it is Twitter's UI ("oops, page reloaded, back to the top you go") and part is

that it is

a little maddening to

read thoughts br

oken up into smaller

chunks and not

paragraphs.

That said, I agree more with my first paragraph than my second so I get it, and perhaps if I can't follow or respect the creator's wishes in how to consume the content that he or she created in the manner it was created, maybe I shouldn't consume it at all?

<comment><USER7> > perhaps if I can't follow or respect the creator's wishes in how to consume > the content that he or she created in the manner it was created, maybe I > shouldn't consume it at all?

I _strongly_ disagree. While I also think that creators should be compensated for their works (for a limited time), after they get said compensation, they should get _no_ say in how you consume the content, or what you do with it (with the obvious exception of making it available to others).

<comment><USER8> > after they get said compensation, they should get no say in how you consume > the content

We need universal basic income alongside the abolition of intellectual property law.

<comment><USER9> One part of IP law that needs to remain is attribution. We don't want people copying others work and claiming they made it.

Another part is trademark law. It should not be possible for e.g. coca cola to make Pepsi cans with horrible tasting drinks inside.

However, most of Patent law, and a lot of Copyright law should be scrapped.

<comment><USER10> > Another part is trademark law. It should not be possible for e.g. coca cola > to make Pepsi cans with horrible tasting drinks inside.

I'm pretty sure that falls more under fraud than it falls under trademark violation.

<comment><USER11> Trademark law functions as an extension of laws against fraud. It really doesn't have much to do with copyrights nor patents.

</comment></comment></comment></comment></comment></comment><comment><USER12> The sites making articles from these threads is definitely an issue, though my experience is they don't exactly need these bots to do so. A disturbingly high percentage of articles on sites like BuzzFeed and Dorkly are basically just 'here are ten screenshots of Reddit posts about X', and those likely weren't done with bots. Lazy media sites reposting social media posts is its own issue.

Thread compiler apps and sites on the other hand... well I'm a bit more torn there. On the one hand, yeah, I guess it's not right if you're just reprinting others' work without their permission. But at the same time, most of these services do let you embed content, and do have an API. Isn't that basically what they exist for?

And aren't you already not getting paid for your work by using these services? You're not getting paid for posting on Twitter.

<comment><AUTHOR> _You 're not getting paid for posting on Twitter._

Some writers are monetizing their Twitter threads. For example:

[https://www.patreon.com/user?u=4846197](https://www.patreon.com/user?u=4846197)

<comment><USER13> This is an interesting angle! If these Twitter users could login to these thread reading apps and maybe attach a Patreon link to their accounts, is that a happy middle ground? Also, what if they link to their Patreon/Square Cash/PayPal/Venmo at the end of every thread? That will also get posted to these thread unrolling sites.

<comment><USER14> Twitter could help users monetize by adding a Flattr-like micropayment system where you could "tip" a tweet instead of just liking it. Likes could be more than just social currency. Twitter could make money off the float of money in tippers' and tippees' accounts. This might lead to more meme content theft because people would want to get tipped for other people's popular content.

Or Twitter could allow content creators could charge a subscription fee to be followed. Creators could allow their tweets to become public after a configurable number of hours so non-subcribers could see what they're missing.

</comment></comment></comment></comment><comment><USER15> I don't see a problem with people who aggregate content for money. They're providing a valuable service sifting through the vast sea of potentially interesting content and presenting it in a manner that is efficient and entertaining to consume. The information itself is not valuable, _being shown that information in an efficient and timely manner_ is valuable. If you've posted your ideas or works freely on a platform that does not restrict access to it (Twitter, Reddit, HN, etc), then it is not a scarce resource and simply does not have value that can be stolen from you. Aggregators are giving it value by making it visible to their audience.

This all feels analogous to someone telling a joke to their friends. One of the friends taking the joke and claiming it as their own is a dick move, but we all accept that the joke was freely given away and that the other friends aught to be able to retell it without being forced to credit the original author every time they retell it (or pay them if they make money telling it at some point). It's an idea; once you freely enter it into the public sphere you don't and shouldn't have control or ownership anymore; it belongs to society.

</comment><comment><USER16> Do you know why "thread compiler apps" exist and have userbase? Because your 50-part "story/article" on twitter is unreadable waste of time for some people and they invented solution for this problem.

<comment><USER17> She addresses that in the original thread — her twitter threads are specifically for her followers; they're not blog posts.

<comment><USER18> Do her followers have to use first party twitter clients? Are these thread compilers different than third party clients?

<comment><USER17> 1) I don't think so.

2) They're different because they usually store and distribute her data somewhere other than twitter. If she deletes a thread, that copy persists. If people interact with that copy, she doesn't get to see or manage that. If it's through twitter's API, she can see interaction with her content and block people if they interact abusively. And third party clients generally don't profit off of individual threads.

[https://bobbin.herokuapp.com/](https://bobbin.herokuapp.com/) is a compiler that is much more like a third party client; it all goes through twitter's API, and in follow ups she said it sounds fine.

</comment></comment></comment></comment><comment> kyle-rb I agree with the author completely in regard to the low-effort articles simply rehashing Twitter threads. I'm not sure if fair use would even be taken into account in this case, but I feel like this isn't transformative, and it's aiming to provide a replacement product.

However, I disagree on thread readers. They provide attribution to the author, so a reader has just as much opportunity to click through to the author's page as they would within the default Twitter client.

Yes the thread reader is getting ad revenue from displaying the content, but this isn't really money that the author would have seen anyway. If anything, Twitter is the one getting ripped off, so it's in their interest to improve the native thread reading experience, to capture back that lost revenue. The author says that they're not providing any added value, but I think their value is the improved readability of the thread.

Overall I think she's discounting the improved readability that these sites provide. She mostly just mentions that they improve shareability, which for me is a secondary benefit at best.

</comment><comment><USER19> One would think that after nearly three decades of internet we'd all have agreed on this. It's not 'your' feed, it is content you posted on a public forum. If you want to monetize it, find an audience and sell them your content in private, or generate revenue from the exposure.

<comment><USER20> I think normal copyright laws would apply, beyond small passages being quoted (except for maybe that Twitter's terms allow embedding tweets, thus creating a workaround). I can't just legally put together a PDF of all your HN comments called "ricardobeat's thoughts" and sell it at $40 a pop.

<comment><USER21> But you could do so with YCombinator's permission.

</comment></comment></comment><comment><USER22> I feel that blogposts or videos which are basically rehashes of viral Twitter threads or Reddit posts are quite sleazy.

My intuition is "repackaging, redistributing, or transforming freely available things" isn't a problem. But trying to make money from it is.

I can understand it's a pain if you're producing content regularly which is well received, but you're not paid for it.

I think that parallels the open-software stuff at the moment. (Licenses and creative-commons seem analogous in this case).

I think that "Donate to my Patreon to support my content creation" has worked out okay, though. It seems to have given more people more money than they'd otherwise get from a "only consume if you've paid" model. (Although 'Patreon supported' doesn't solve the sleazy redistribute-with-ads).

</comment><comment><USER23> I get her point. But I have zero patience for Twitter. I've tried it. And it's just too fragmented for me to bother with.

The only way I could vaguely make sense of it is through thread-compiling clients. But I never found a good one for Linux. Is there one?

But websites that compile Twitter threads, and then serve them via apps, with ads? That's just fucking insane. I mean, just put the bloody thread compiler on Github ;)

</comment><comment><USER24> ctrl+f 'transformative'... No matches.

I'm surprised by the sympathy I'm seeing for this position. You people know that she is effectively complaining about fair use, right? This is not something that can be budged on, even in deference to the feelings of a "writer/feminist/educator". Fair use is the only thing that stands between us and massive intellectual property cartels guiding the public consciousness through selective enforcement. Wanna go back to network television? Because this is how you do it.

<comment><USER25> Fair use isn't a blanket excuse to do whatever you want. The key component is whether your use is transformative. If you copy something to criticize it, or make something that doesn't compete with the original, it's likely fair use. If you copy something just to have it, or build upon it, it's not. This is a new issue, but copying someone's tweets, just to create your own library of tweets is not really transforming anything, I don't see how this is fair use.

<comment><USER24> Google "Richard Prince copyright". This is not a new issue, not even close.

BTW... She is using a still[0] from a video that CNN owns the copyright to, and section 3 of their tos[1] explicitly forbids doing what she is doing - with the unnecessarily stated exception "as otherwise expressly permitted under copyright law". You really want to take that exception away from her? I can pretty easily argue that her use is transformative, can you? How does this differ from what she is complaining about?

[0] [http://www.erynnbrook.com/white-feelings-for- charlottesville...](http://www.erynnbrook.com/white-feelings-for- charlottesville/) [1] [https://www.cnn.com/terms](https://www.cnn.com/terms)

<comment><USER25> How is the use of that photo transformative in anyway? Did she add to it? Is the piece about criticizing the photo (which would be transformative) or is she using it as part of an opinion news piece (which isn't)?

And btw, the Prince case is illustrative because the judge ruled that some of his pieces were transformative, but others were not, walking that gray line.

</comment></comment></comment></comment><comment><USER26> > She didn't know until after it had flown away that she should copyright it.

The default is for works to have an automagic copyright so you have to give it away (though a permissive license or public domain if your country supports that concept) else nobody can legally share it.

Think what she meant to say is she should have put her name on it so she got some interweb points.

</comment><comment><USER14> That these third-party Twitter thread compilers exist means that Twitter needs to fix their threading UI.

</comment><comment><USER13> Coming back to this though...I'm kind of interested in other things that makes content easier to consume. Instapaper, Pocket, other RSS apps, etc...yes, you have the original source and all that, but isn't it taking it away from the original medium in a way? Not sure if this is an apples to oranges comparison.

<comment><USER27> Well, if you start going on that path you'll also reach the complicated topic of ad-blocking. It's all about dividing control how content can or should be consumed, and how should various parties involved be compensated.

</comment></comment><comment><USER28> The DCMA provides exceptions for caching. But in order to be a cache you need to eventually and automatically reflect the wishes of the source. So, if the original content disappears it has to disappear from the cache too. Or, if the original content changes it has to be reflected in the cache too.

In the case of twitter, there is no equivalent for a per-account "robots.txt" and issues like this arise where you can't take your content back once it's copied. Twitter thread compilers should regularly check whether a tweet has been removed etc to turn into a cache and avoid these situations.

<comment><USER3> The DMCA (and copyright in general) is probably not relevant, because every Twitter user grants them essentially a license to do anything with their tweets, including sublicense them and such, so it's probably up to Twitter to revoke that permission if they wish.

</comment></comment><comment><USER29> > But imagine what she'd have if her name was attached to every instance of > the image, doctored or not?

Then her name would be connected to a silly joke forever.

</comment><comment><USER30> I believe the legendary Project Xanadu has an interesting approach, possibly restrictive, for dealing with this issue.

[http://xanadu.com/xuTheModel/](http://xanadu.com/xuTheModel/)

</comment><comment><USER31> Try [http://tippin.me/](http://tippin.me/) \- we can only overcome the predatory economics of these platforms by experimenting

</comment><comment><USER32> So how about Twitter thread compiler that's just a bunch of static JS on a CDN, that takes all its data from the URL and compiles threads client-side?

That ought to be fair under copyright law.

</comment><comment><USER33> Whenever I see a twitter thread I immediately do not read it.</comment>


RJSON: compress JSON to JSON - <AUTHOR> http://www.cliws.com/e/06pogA9VwXylo_GknPEeFA/

<comment><USER2> I see a pretty major problem with this. It seems to depend on the order of key value pairs in object literals being defined. The order is not defined by the JSON or the ecmascript standards. So you can't really depend on the order of keys in a json object, unless you explicitly define some order (like alphabetical, for instance). I like the basic concept of compressing json to json but this is not a particularly good way to do it- since the order of those keys may not be preserved in round trips through json encoders and decoders in various languages.

<comment><USER3> I saw the same thing right away. Seems like the first item in the array would have to be used as a hash of key/index pairs to be used for the following items. I guess this would only be useful with large sets of data, the examples makes them look kind of silly =)

So this:

        "users": [
            {"first": "Homer", "last": "Simpson"},
            {"first": "Hank", "last": "Hill"},
            {"first": "Peter", "last": "Griffin"}
        ],

Becomes:

        "users": [
            ["first", "last"],
            ["Homer", "Simpson"],
            ["Hank", "Hill"],
            ["Peter", "Griffin"]
        ],

<comment><USER4> Doesn't this introduce ambiguity? How do you represent list of 'tuple lists'?

<comment><AUTHOR> You can see it in the unit tests: [https://github.com/dogada/RJSON/blob/master/test/tests.js#L4...](https://github.com/dogada/RJSON/blob/master/test/tests.js#L43)

</comment></comment></comment></comment><comment><USER5> Would like to emphasize that this is only really useful in environments where gzip is not available (as the OP notes)...some tests using the demo JSON (minified):

test.json = 285 bytes

test.rjson = 233 bytes (18%)

test.json.gz = 205 bytes (27%)

If you are able to bundle a RJSON parser, why not just bundle an existing, well understood/tested compression scheme such as <http://stuartk.com/jszip/> or [https://github.com/olle/lz77-kit/blob/master/src/main/js/lz7...](https://github.com/olle/lz77-kit/blob/master/src/main/js/lz77.js) instead?

<comment><USER2> An arithmetic coding scheme which has a model based on the probabilities found in JSON abstract syntax trees would significantly improve on most typically used generic compression schemes. Arithmetic coding schemes have largely been avoided thus far due to patents which have recently expired, if I remember correctly.

using the order 2 precise model on this page I get 190 bytes-- and that is still a generic non-json model. <http://nerget.com/compression/>

<comment><USER5> This - JSON specific compression schemes aren't going to yield gains over AST friendly schemes unless the JSON serialization specification changes significantly.

Along these lines - shipping a schema with the data payload is avro-like ... which is also questionable in terms of efficiency when compared with gzip/LZO.

<comment><USER2> hey look, I found this <http://research.microsoft.com/en-us/projects/jszap/>

<comment><USER5> They are using gzip compression level 1. Bogus.

<comment><USER2> Are you referring to the graph, in which they set the gzip compression as "1" in order to clearly show the ratio of compression improvement that their technique has over gzip?

</comment></comment></comment></comment></comment></comment><comment><USER6> > reduce JSON data size and network traffic when gzip isn't available. For > example, in-browser 3D-modeling tools like Mydeco 3D-planner may process and > send to server megabytes of JSON-data;

`Content-encoding: gzip` anyone?

<comment><USER7> I don't believe that browsers let uploads be gzipped, as it can't be sure that the server supports gzipped requests.

<comment><USER6> Good call. I would think there should be a way to specify it... Something to look into I guess.

EDIT: or as a comment above states, compress (gzip/deflate) it yourself. Not the most elegant, but if space is an issue.

</comment></comment></comment><comment><USER8> Good idea but i think for those extreme cases where you really have use for this you might as well go with a specialized protocol, which can be based on json if you need it.

I had to do this for an application which streamed several hundreds of data points per second to a browser-client. Both data-size on the network and parsing time in the browser was my biggest issues. Since it was a html-app i had to use either JSON.parse or custom parsing written in javascript, the second option being too slow to be viable. I ended up with something based on almost only json-arrays and then the client would know what the different items in the array meant. With his example it would only look something this: [7, ["programming", "javascript"],["Peter", "Griffin", "Homer", "Simpson", "Hank", "Hill"]]

So in other words it's just enough overhead to make it parsable by json.parse but otherwise you only transfer the actual data.

Note that I wouldn't recommend this option unless you really hit a wall where you realize that this in fact is a bottleneck.

<comment><AUTHOR> RJSON not only compresses data of any structure but keeps it in JSON format that is huge advantage over gzip/7z and other binary compression algorithms. You can compress 1M of JSON to 300Kb of gzipped JSON but then you will to parse 1Mb of JSON on client anyway. With RJSON you can compress 1Mb of JSON to 500Kb of RJSON, then gzip it down to 200Kb and parse only 500Kb of JSON. Then you can analyze some core properties of parsed RJSON document and unpack it on demand. For example you may send to client collection of 20 documents, parse each and show title of each document to the client, then fully unpack only selected by client document.

I agree with Too that specialized protocol will always win, but RJSON IMO decreases structural entropy almost to 0 without need to debugging own protocol.

</comment></comment><comment> uncle-ezra If your HTTP connection is going to be gzip compressed, then manual compression of this kind is not guaranteed to reduce the size of the final result, and may in fact hurt it.

<comment><USER9> If your HTTP connection is going to be gzip compressed, then this will only give you monetary savings to compensate for the additional code complexity if you have medium to big data, at which point storing it in JSON is a questionable-at-best proposition.

</comment></comment><comment><USER10> How would it compress and then decompress the following document?

      {"users": [
        {"first": "Homer", "last": "Simpson"},
        {"first": "Hank", "last": "Hill"},
        [2, "Peter", "Griffin"]
      }

<comment><USER11>
        {
            "users": [
                {
                    "first": "Homer",
                    "last": "Simpson"
                },
                [
                    2,
                    "Hank",
                    "Hill"
                ],
                [
                    0,
                    2,
                    "Peter",
                    "Griffin"
                ]
            ]
        }

There was a tester linked from the site. Looks like he added the [0, to handle that case.

<comment><AUTHOR> Yeah, for arrays with first numeric value is reserved schema with index 0. You can see more examples in the unit tests: <https://github.com/dogada/RJSON/blob/master/test/tests.js>

<comment><USER12> Unit test suggestion: testPackAndUnpack should also check double-compress and double-decompress for being identical, it'll tend to find any remaining such issues, if any.

<comment><AUTHOR> Thanks, jerf, done: [https://github.com/dogada/RJSON/commit/0a7fc5dd9e142477ebda9...](https://github.com/dogada/RJSON/commit/0a7fc5dd9e142477ebda93f3197ea346a7aff13a)

</comment></comment></comment></comment></comment><comment><USER13> I wondered if it was April Fools day... Really, JSON is lightweight enough that it doesn't need compressing. We're not dealing with XML here! This just adds another point of failure.

</comment><comment><USER14> If you just use GZIP, supported by most browsers, it compresses without the need of special software on the client side to rebuild the original JSON response. And does a better job at compression I bet. I thought of doing something like this to rebuild cycles in object graphs, but I didn't because it requires special parsing logic for the client to use.

</comment><comment><USER15> similar to JSONH, which i use to pass recordsets back and forth. there's no recursiveness for nested stuff though.

<https://github.com/WebReflection/JSONH>

</comment><comment><USER16> dogada, do you have any results showing both size reduction, and speed of compression/decompression vs. other methods?

<comment><AUTHOR> On algorithmic level compression is mainly identical to JSONH. I didn't do performance tests yet, I still have ideas how to improve RJSON.

</comment></comment><comment><USER17> It's all fun until someone loses an eye.

What if i look at your API output and assume it's json (only got unique items) but it's rjson? Or whatever?

The most important thing when adding another layer to a protocol is identification.

So, please, put the whole altered object into a rjson root node so it's clear what we're dealing with.

<comment><AUTHOR> I agree that identification is important issue, but IMO it's protocol level issue. RJSON is not protocol, it's algorithm. Someone will prefer to wrap all in {"rjson": ...}, someone like {"format": "rjson", "data": ...} and so on. I belive, algorithm itself should create as less limitations as possible.

<comment><USER18> The MIME type is allowed to add information about the nature of the data encoded on top of the encoding. This is why we have application/xhtml+xml. It means "this is encoded using xml, and btw the parsed xml structure is xhtml".

The ideal place to handle this is (as pointed out above) content negociation - specifically as 'application/rjson+json'</comment></comment></comment>


Show HN: An Accurate Whistle Detector I Made in JavaScript - <AUTHOR> https://stuff.shubhamjain.co/whistlerr/ <comment><USER2> I get more false negatives than false positives.

Perhaps you can add a sliding button to select the sensibility, with a good default value. (Don't show the number, only the slide.)

You can track if most people move the sensibility threshold and modify the default value.

\---

Is the sound processed locally or it is send to your server?</comment>


Whats a good place to get a list of all popular tech conferences? - <AUTHOR>

I know theres PyCon, DjangoCon, Strange Loop, RubyConf, OSSCon, and probably a bunch others. Does anyone know of a list of popular conferences? I really like watching the videos, and would like to some day get into doing talks at these conferences, but it seems that I always learn about a conference after talk submissions are due. <comment><USER2> Have you tried <http://lanyrd.com> ?

</comment><comment><USER3> <http://meetup.com></comment>


Glenn Beck says Eve Online's Goonswarm is a CIA front - <AUTHOR> http://www.mmorpg.com/gamelist.cfm/loadNews/25579/Glenn-Beck-Goonswarm-a-CIA-Front

<comment><USER2> We're giving Glenn Beck airtime why?

</comment><comment><USER3> so apparently I'm part of a CIA front

<comment><USER4> That me in TEST ex-KGB then.

And yes, we're spiraling deep down a meta rat hole here.</comment></comment>


Ubuntu Switches to a Snap'd Software Store for 20.04 - <AUTHOR> http://www.tuxmachines.org/node/134641 <comment><USER2> Of course the snap'd version has no support for flatpak apps.</comment>


Why can't Apple decrypt your iPhone? - <AUTHOR> http://blog.cryptographyengineering.com/2014/10/why-cant-apple-decrypt-your-iphone.html <comment><USER2> There's another technical surveillance method here that I feel more people should be talking about: monitoring iMessage communication.

iMessage is extremely secure[1], except for the fact that Apple controls the device list for iCloud accounts. The method would simply be for Apple to silently add another device to a target's account which is under law enforcement's control. I say "silently" in that they would need to hide it from the target's iCloud management UI to stay clandestine, but that's it, just a minor UI change. iMessage clients will then graciously encrypt and send a copy of every message to/from the target to the monitoring device.

This would still work even with impossible-to-crack encryption. It wouldn't allow access to old messages, just stuff after the monitoring was enabled. It's the modern wiretap.

It mirrors wiretapping in that sufficiently sophisticated people could discover the "bug" by looking at how many devices iMessage is sending copies to when messaging the target (just inspecting the size of outgoing data with a network monitoring tool would probably suffice), but it would go a long way and probably be effective for a high percentage of cases.

The main thrust of the article is that encryption is not new, just the extent of it, particularly iMessage. Here's a way around that.

[1] [http://images.apple.com/iphone/business/docs/iOS_Security_Fe...](http://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf)

<comment><USER3> Whenever you add a device to your pool of iMessage devices, all of the other devices get a popup message telling them. This is the step where each of the other devices get the decryption key for that device.

My hunch is that Apple doesn't have a way to prevent the popup messages so if they were forced to add a law enforcement iPhone to an iMessage pool then the target would notice an extra device was added.

<comment><USER4> Maybe I don't understand the problem, but it seems to me that it would be very simple for apple to prevent the popup messages at their discretion, since they write and control the software that _causes_ the popup to happen in the first place.

<comment><USER5> They would have to update the OS on the device first. And that's definitely not something that can be done silently.

I'm assuming here that the OS already doesn't have the ability to suppress the popup, and I think that's a safe assumption because Apple _doesn 't want_ to have this ability.

<comment><USER6> _> They would have to update the OS on the device first. And that's definitely not something that can be done silently._

how do we know that the iMessage protocol doesn't _already_ have support for a "silent" flag, which, if set, will not cause the message to appear?

<comment><USER5> I already answered that in the second sentence of my comment.

</comment></comment></comment></comment></comment></comment><comment><USER7> > The Secure Enclave is designed to prevent exfiltration of the UID key. On > earlier Apple devices this key lived in the application processor itself, > and could (allegedly) be extracted if the device was jailbroken and kernel > patched.

Speaking as a jailbreaker, this is actually incorrect. At least as of previous revisions, the UID key lives _in hardware_ \- you can ask the hardware AES engine to encrypt or decrypt using the key, but not what it is. Thus far, neither any device's UID key or (what would be useful to jailbreakers) the shared GID key has been publicly extracted; what gets extracted are secondary keys derived from the UID and GID keys, but as the whitepaper says, the passcode lock key derivation is designed so that you actually have to run a decryption with the UID to try a given passcode. Although I haven't looked into the newer devices, most likely this remains true, since there would be no reason to decrease security by handing the keys to software (even running on a supposedly secure coprocessor).

<comment><USER8> Is jailbreaking becoming more difficult and would that be a sign of iOS/iPhone becoming more secure?

<comment><USER9> It's a _step_ towards becoming more secure. Having control of your operating system (that is, preventing other programs from taking control prior to the operating system starting up), is clearly a desirable behavior if you want to prevent applications like keyloggers, data sniffers, etc...

</comment></comment></comment><comment><USER10> Now if only it was possible to turn off remote installation of applications on both iOS and Android devices, this kind of security would actually mean something.

Right now, you can do full disk encryption on an Android device (which seems likely to become hardware-assisted on future devices similar to the solution mentioned in the article). If you pick a sufficiently strong passphrase, that should keep your data secure even on devices without hardware assistance. However, if the device is turned on and locked (the common case), it's trivial to remote-install an arbitrary app, including one that unlocks the phone. (You can do this yourself with your Google account, which means anyone with access to that account can do so as well.)

It would help to be able to disable remote installation of any kind; that wouldn't have to come at the expense of convenience, because the phone could just prompt ( _behind the lockscreen_ ) to install a requested app.

<comment><USER11> As far as I know, it can install an app _but not run it_ (EDIT: on Android, that is). So it shouldn't be able to do any such decryption.

<comment><USER12> The problem is the attack surface for an app on a device vs. in the wild is much, much larger and much, much less secure.

Once its on your phone, it can just screenshot things if nothing else.

<comment><USER13> Android requires root privilege and/or system-level app to take screenshots. iOS is probably similar. I don't think an app could spy like this without user enabling it (which is a valid but separate concern about how knowledgeable the average rooter/jailbreaker is.)

[0] [http://android.stackexchange.com/questions/10930/why-do- we-n...](http://android.stackexchange.com/questions/10930/why-do-we-need-a- rooted-phone-to-capture-screenshots)

<comment><USER14> Maybe I'm not fully understanding here but the last two phones I've used do not require root or any app to take screenshots. Nexus 5 and Moto X.

<comment><USER13> By root, I meant that an app with root access could probably take screenshots, not that a root app is needed for the user to access the system's screenshot capability.

</comment></comment></comment></comment></comment></comment><comment><USER15> If someone obtains your phone, and prevents you from initiating a remote wipe (perhaps they have you in custody, or perhaps they have isolate the phone so that it cannot receive the wipe command), it sounds like this technology will do a good job of preventing them from decrypting your data from the phone if you have a decent passcode. They cannot throw GPUs or FPGAs or clusters or other custom hardware at the problem of brute forcing your passcode because each attempt requires computation done by the Secure Enclave using data only available in the Secure Enclave. That limits them to trying to brute force with no parallelization and 80ms per try [1].

However, assuming they have an appropriate warrant, can't they get your iCloud backups and try to brute force those? Maybe I'm being an idiot and overlooking something obvious, but it seems to me the encryption on the backups CANNOT depend on anything in the Secure Enclave.

That's because one of the use cases that iCloud backup has to support is the "my phone got destroyed, and now I want to restore my data to my new phone" case. To support this, it seems to me that the backup encryption can only depend on my iCloud account name and password. They can throw GPUs and FPGAs and all the rest at brute forcing that.

My conclusion then is that when I get a new iPhone, I should view this as a means of protecting my data on the phone only. It lets me be very secure against an attacker who obtains my phone, but not my backups, provided I have a good passcode, where "good" can be achieved without having to be so long as to be annoying to memorize or type. A passcode equivalent to 32 random bits would take on average over 5 years to brute force.

To protect against someone who can obtain my backups, I need a good password on iCloud, where "good" means something considerably more than equivalent to 32 bits.

[1] I wonder if they could overclock the phone to make this go faster?

<comment><USER16> Yes, currently iCloud backups are not encrypted so they can be extracted by law enforcement, but on the other hand they are not mandatory, as Apple also offers a full local backup solution through iTunes (albeit, admittedly, they could make it work automatically like Time Machine, instead of manually; I guess they'll get there, now that they're using privacy in marketing).

On the other hand, it is perfectly possible to devise a system to locally encrypt iCloud backups and still be able to restore them. Look at how iCloud keychain works, in the Apple documents, as those datas (= all your passwords and secrets) are synced through the cloud between your devices but Apple can't access them. For iCloud keychain, in case you lost access to all your devices, you need a master recovery key that's generated when you first activate it; if you don't have it, you lose the data.

<comment><USER17> > iCloud backups are not encrypted

This is wrong. iCloud uses AES 128 and 256 encryption:

[http://support.apple.com/kb/HT4865?viewlocale=en_US&locale=e...](http://support.apple.com/kb/HT4865?viewlocale=en_US&locale=en_US)

<comment><USER18> This doesn't really say much unless we also know how the AES key itself is derived.

If you don't have two-step authentication on, then Apple's password reset is based on asking some security questions and sending an e-mail challenge. Even if they actually derived the key from your security question answers (unlikely), that's the kind of thing law enforcement would have no trouble cracking. More likely, the whole authentication system simply returns true or false, and the key is stored in some separate place -- perhaps more secure than a random hard drive in the datacenter, but still somewhere where Apple can get it if forced.

If you _do_ have two-step authentication enabled, Apple's docs imply that it is impossible to recover your account without at least two of:

* Your password.

* Your "recovery key" \-- a secret that they give you and instruct you to print out and keep somewhere.

* Your phone (or some other device that can generate one-time codes).

They say that if you can't produce two of these then all your data is lost and you'll need to create a new Apple ID. This implies that they might indeed store your data encrypted by an AES key which is in turn stored encrypted in two different ways: once with your password, and once with your recovery key. Thus it would actually be impossible to recover your data without one of these, and Apple doesn't store either one on their servers, therefore Apple would not be able to produce your data for law enforcement.

That said, I would be _very_ surprised (and impressed) if Apple actually does this. Consider that this would prevent their services from doing any offline processing of your data at all -- a compromise few product designers would be willing to make for a security guarantee that almost no user actually understands. More likely, the language in the documentation is a matter of policy -- Apple refuses to recover your account simply because that's the only way to guarantee that social engineering is impossible, not because they are technically incapable.

And anyway, even if your data is stored encrypted at rest with a key that is actually derived from your password, there's nothing stopping law enforcement from demanding that Apple intercept your password (or the key itself) next time you log in. That's basically what they did with Lavabit, after all.

(Things I think about while working on sandstorm.io...)

</comment></comment></comment></comment><comment><USER19>
       1. [...]
       2. [...]
       3. [...]
       4. [...]
       5. The manufacturer of the A7 chip stores every UID for
          every chip.

I'm a total layman, but the UID has to be created at some point and so it can be known by someone. Wouldn't it be the easiest way to just record it for every chip? Apple wouldn't even have know about it.

<comment><USER20> This is the fundamental problem: unless you are rolling your own silicon, at some point you have to take some big corporation's word for it that a chip does what they say it does. This fundamental problem is the reason that nuclear launch codes are protected by a relatively low-tech solution:

[http://en.wikipedia.org/wiki/Gold_Codes](http://en.wikipedia.org/wiki/Gold_Codes)

<comment><USER19> But if this is the case, why bother with bullet point 1. to 4. The chip is probably manufactured in China, why spend a thought about whether US law enforcement can somehow via Apple decrypt the data of my phone when the Chinese Government can do it anyways?

<comment><USER21> I fear the American government's totalitarian/police state leanings far more than I fear the PRoC.

Though the Chinese government is undoubtedly an enthusiastic squasher of political dissent, and their secret police are surely quite brutal, and I hate commies with a passion, I am hardly ever likely to have a conflict with the Chinese state.

An Unconstitutional American surveillance state is a far more immediate problem. The NSA can break down my door tomorrow after reading my politically unpalatable text messages, and there's nothing I can do to stop them. So if I had to pick someone to have the keys to my phone's backdoor, I'd pick a "hostile" foreign power any day. Though of course it would be better to have no backdoors at all :)

<comment><USER4> I agree with you, but I would add that: if _any_ power has the key to your phone's backdoor, there is a chance of the key getting into the NSA's hands.

</comment></comment></comment></comment></comment><comment><USER22> > (Apple pegs such cracking attempts at 5 1/2 years for a random 6-character > password consisting of lowercase letters and numbers. PINs will obviously > take much less time, sometimes as little as half an hour. Choose a good > passphrase!)

Do not use simple pin passwords on your phone. In particular, if you use fingerprint access, there is no reason not to have a long, complex password.

<comment><USER23> There is an argument against using the fingerprint access and that is that a user gives up the right of consent while in custody. If law enforcement gets a judicial order to forcibly press the prisoner's finger to the sensor to unlock the device, then he or she has little recourse as the right to remain silent is not implicated. One cannot be similarly physically compelled to disclose a code only held in his or her memory.

<comment><USER24> _> One cannot be similarly physically compelled to disclose a code only held in his or her memory._

Are you sure? In the UK and I'm pretty sure in my native Australia, they definitely can, under pain of "contempt of court".

<comment><USER23> That gets into key disclosure law and it does vary by jurisdiction. Though I am not a lawyer, it is my understanding that this is an area of dispute in the United States with respect to the 5th amendment, which forbids the government the power to compel one to ever testify against him or herself.

Even under a mandatory key disclosure regime, it's still a choice to remain silent even if that means one remains jailed. That situation sure seems like a form of torture to extract information from the incarcerated individual.

This 2012 Forbes article is a good read on the matter: [http://www.forbes.com/sites/jonmatonis/2012/09/12/key- disclo...](http://www.forbes.com/sites/jonmatonis/2012/09/12/key-disclosure- laws-can-be-used-to-confiscate-bitcoin-assets/)

</comment></comment></comment></comment><comment><USER9> I read through the article - including the hand wavey "Apple has never been cracking your data conclusion" \- but I don't understand what has changed since previous versions of iOS other than more data being encrypted.

Apple claims they can't decrypt data, but, the article suggests that they can simply run the decryption on the local phone with custom firmware. Most people chose a 4 digit pin, and, @80 millisecond/guess, that means Apple should be able to crack your phone in 12 minutes.

If you use a longer passcode, your data is more secure - but I thought that was _always_ the story with Apple.

So what, if anything, has changed (other than more data being encrypted?)

<comment><USER25> The passcode and the pin is not the same thing, most people don't have a passcode.

<comment><USER9> Re: "The passcode and the pin is not the same thing, most people don't have a passcode."

On iOS I believe this is incorrect, the Passcode is another name for PIN on the iPhone.

[http://support.apple.com/kb/ht4113](http://support.apple.com/kb/ht4113)

You can have complex or simple passcodes, but everybody I've ever seen who bothers to have a passcode (myself excepted), sets it to a 4 digit code (aka PIN). To make it worse, it's usually their ATM PIN.

</comment></comment></comment><comment><USER26> Invasive attacks for extracting the UID depend on exactly how it's 'implemented in hardware'.

It could be a total lie, and hardwired or masked-rom per-revision (but I doubt that, too easy to discover)

It could be in a one-time programmable block somewhere that gets provisioned during manufacture - a flash block/eeprom with write-only access (externally at least), or a series of blowable fuses, or even laser/EB-trimmed traces.

All of those 1-time prog methods are susceptible to the person operating the programmer to record the codes generated, although managing and exfiltrating that much data would make it rather tricky.

The method of storage also influences how hard it is to extract through decapping and probing/inspection.

If I had to design something like this (note: not a crypto engineer), I'd have some enclave-internal source of entropy run through some whitening filters, and read from until it meets whatever statistical randomness/entropy checks, at which point it is used to seed & store the UID into internal EEPROM. That way, there's no path in _or_ out for the key material, except when already applied via one of the supported primitives.

Then you need to protect your secrets! Couple of layers of active masks (can they do active resistance/path-length measurements instead of just continuity yet? That would annoy the 'bridge & mill' types :)) Encrypted buses, memory, and round-the-houses-routing is also pretty standard for the course, but I'm sure it too could be improved on.

IIRC there was someone on HN who was working for a TV smartcard mfgr who was reasonably confident they'd never been breached. Curious what he'd have to say (without an NDA :) )

<comment><USER26> Edit: I wonder if anyone is mask/shielding against back-side attacks yet? I did like the buried light-sensors dotted around some hi-sec core I was watching, although they didn't end up being particularly useful.

My understanding here is that this Enclave is just a specific part of the overall die, so they're somewhat constricted in the crazy-fabtech methods they might otherwise be able to consider.

</comment></comment><comment><USER27> > Apple doesn't use scrypt. Their approach is to add a 256-bit device-unique > secret key called a UID to the mix, and to store that key in hardware where > it's hard to extract from the phone. Apple claims that it does not record > these keys nor can it access them.

Technically, this is where it breaks down. As in "Trust me I don't store the keys."

If that hypothesis is true(they don't store these keys), then they'll have a hard time breaking your encryption indeed. But you must trust Apple at that point.

If there was a way to buy an anonymously replaceable chip with this cryptographic key in it and replace it on the phone like a SIM, then we'd be much closer to stating "Apple can't decrypt your phone".

<comment><USER28> Right. We'd instead be having a discussion about how Atmel can decrypt your phone.

<comment><USER27> It was just an example how you could detach the secret and the device made by Apple. I'm sure there are better ideas for that. The way this is configured now Apple _can_ decrypt any phone, which voids the argument made in the OP. But I can understand why this will be the unpopular opinion here.

</comment></comment></comment><comment><USER29> > Secure Enclave allows firmware updates -- but before doing so, the Secure > Enclave will first destroy intermediate keys. Firmware updates are still > possible, but if/when a firmware update is requested, you lose access to all > data currently on the device.

Given that the end-user has entered the passcode it shouldn't be hard to retain the data: after upgrading the Secure Enclave firmware simply unencrypt all data using the old key and reencrypt it using the new key (derived from same passphrase but a new UID).

You can also use a "two stage" approach where the encryption key derived in hardware is only used to protect a secondary key. In this case you just reencrypt this secondary key which in turn protects the data.

</comment><comment><USER30> Is Apple's "Secure Enclave" anything more than ARM's TrustZone?

[http://www.arm.com/products/processors/technologies/trustzon...](http://www.arm.com/products/processors/technologies/trustzone/index.php)

<comment><USER31> Contrary to speculation ( there are whole articles which "explain" the secure enclave to be ARM trustzone) secure enclave is documented ( only very recently) to be a _seperate_ chip inside the A7 chip running it's own L4 based microkernel. (From [https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...](https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2014.pdf))

" The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series processor. It utilizes its own secure boot and personalized software update separate from the application processor. It provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised.

The Secure Enclave uses encrypted memory and includes a hardware random number generator. Its microkernel is based on the L4 family, with modifications by Apple. Communication between the Secure Enclave and the application processor is isolated to an interrupt-driven mailbox and shared memory data buffers. "

<comment><USER32> That's pretty much exactly how AMD implements TrustZone. [http://www.anandtech.com/show/6007/amd-2013-apus-to- include-...](http://www.anandtech.com/show/6007/amd-2013-apus-to-include-arm- cortexa5-processor-for-trustzone-capabilities)

<comment><USER33> It sounds more like they are using a Cortex-A5 to gain access to TrustZone with an existing x86 core.

<comment><USER32> And it sounds like Apple is using a separate unspecified ARM processor (probably a Cortex-A5 since that's the cheapest possible one) to gain access to an existing A7 or A8 core.

<comment><USER33> In Apple's case, they use the ARM ISA but implement their own micro architecture and from vvhn's comment seems to also use a co-processor specifically for the secure enclave. But the link above on TrustZone hardware architecture mentions that this isn't a requirement.

"TrustZone enables a single physical processor core to execute code safely and efficiently from both the Normal world and the Secure world. This removes the need for a dedicated security processor core, saving silicon area and power, and allowing high performance security software to run alongside the Normal world operating environment."

I guess since Apple use the ARM ISA, it's still binary compatible with ARM but with a different implementation. AMD uses an x86/ARM hybrid where the ARM part is an off the shelf Cortex-A5 which already contain TrustZone.

<comment><USER32> I highly doubt they use their own micro architecture. It'd be a lot cheaper to license Cortex-A5. Using their own micro architecture for the main processor gives them a huge competitive advantage. For the security co-processor, COTS would work fine.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> What's stopping Apple from being coerced by the PTA (Peeping Tom Agencies) from installing an update to bypass the lock for specific targets?

<comment><USER35> Nothing.

</comment></comment><comment><USER30> > _Apple has built a nuclear option. In other words, the Secure Enclave allows > firmware updates -- but before doing so, the Secure Enclave will first > destroy intermediate keys. Firmware updates are still possible, but if /when > a firmware update is requested, you lose access to all data currently on the > device._

That seems ideal. Let's hope Apple actually does that (probably not).

</comment><comment><USER36> So the key is derived from passcode? isn't that 5 digits that are easy to brute force?

<comment><USER15> 5 digits would be easy. It would take a little over an hour on average. However, passcodes are not limited to digits. Use upper and lower case letters and digits, and then a 5 character passcode would on average a little over a year. Make it 6 characters, and that's 72 years.

<comment><USER9> I'm guessing based on my observations of 40-50 people entering Passcode, that north of 90% of people who bother to use a Passcode (or care to) - use a 4 digit pin.

Even those who are super security conscious tend to just use numeric PINs. It's the very, very rare individual who enters an alphanumeric passcode.

</comment></comment></comment><comment><USER37> Two questions:

* Regarding the fixed 80ms timing: has there been study on the average time needed (aside from the WHY 80ms instead of 70ms or 90ms). I also want to ask for clarification: where is the entire PBKDF2-AES is done? On the AES engine (which I believe is part of the A7 chip)? On a TPM chip (which might be a NO based on unauthenticed source [1])?

* So this UID created in every device and stored in Secure Enclaved which there is a dedicated path between SE and AES engine. But can we conduct any side-channel attack? I am pretty noob with hardware security.

</comment><comment><USER38> I wonder, is it in the realms of possibility for big-budget organizations like the NSA to simply read the UID from the silicon by means of physical analysis (e.g. a scanning tunneling microscope)?

<comment><USER39> It's very probably within the realms of _possibility_ , yes.

It's very probably _not_ within the realms of _practicality_ just yet, however.

<comment><USER26> Go check out some conference presentations by Christopher Tarnovsky. He's made a career out of it, and acquired some very expensive toys (focused ion-beam equipment doesn't come cheap), but there are lectures of his explaining how he broke the (iirc) STMicro TPM chips _for fun_. These sorts of devices have all sorts of countermeasures against direct invasive attacks like these, but with enough cash and bricked test phones, I'd be greatly surprised if it wasn't entirely practical.

The only issue would be making the process so 100% reliable that you succeed first time, because a single mistake or misunderstanding could trash the single copy you have of the code.

I'm curious now if flylogic or chipworks have done any serious teardown of the 'secure enclave' stuff.

<comment><USER9> If the iPhone actually does become very popular, particularly with terrorists, it will be hard to imagine that the NSA doesn't just go develop this capability internally.

"enough cash and bricked test phones" \- the great thing about this, is you can just buy the $650 phones - you can get a thousand of them for less than a million dollars, which probably is under your typical line managers budget in the NSA techOps group.

And, lets be realistic, Apple isn't trying to defend against the NSA or Nation States, just your average hacker without access to $100mm+ in hardware.

</comment></comment></comment></comment><comment><USER40> The security is based on the premise that Apple is unable to decrypt as they do not keep a record of the devices unique ID that is the base of all the cryptography.

What if that is not true? What if the device has a built-in keylogger to just get all the crypto from the user input? be it a passcode or a fingerprint.

Wouldn´t it be partly better if this were based on a trully public key cryptography with a randomly generated private key generated each time the device is factory reset?

</comment><comment><USER41> With all the talks about supper crypto tech use in the Iphone, isn't cloning phone's data as simple as declaring your phone is loss and paying a mobile phone store clerk a new phone and reset the password for the I-Account? The new iphone would have access to all your info, pictures, msg logs in 1-2 hours?

Is this any reasonable PI, police, FBI, hackers can easily social engineer via legal and/or illegal means?

</comment><comment><USER42> What about iCloud? It used to be that a user could reset their password and then restore from iCloud backup on a new phone... Is this no longer true?

<comment><USER43> From what I can understand, if you wanted to hypothetically maximize your security, it would mean turning off iPhone backups.

Apple could also have it set that you must have the iPhone passphrase to restore a backup but obviously those can be "easily" brute forced (because for the restore to work, it must mean you can bypass the old device's UID)

<comment><USER16> You can still fully backup your phone through iTunes, if you want to avoid iCloud backups, until those get encrypted as well.

</comment></comment></comment><comment><USER44> If you're wondering when Secure Enclave first appeared, I looked up the A7 processor. It's in the iPhone 5S, the iPad Air, and the iPad Mini (2nd generation).

</comment><comment><USER45> So the article's answer to "Why can't Apple decrypt your iPhone?" is: "Because Apple says that no software can extract the UID".

In our post-Snowden world this is just ridiculous and intellectually insulting. The author is either naive beyond belief or he got paid to write this PR shill piece.

cf. [https://gigaom.com/2014/09/18/apples-warrant-canary- disappea...](https://gigaom.com/2014/09/18/apples-warrant-canary-disappears- suggesting-new-patriot-act-demands/)

</comment><comment><USER46> And what about a backdoor? Code is not open-source. Just saying..

<comment><USER47> I'm skeptical as well. Seems to me that so many things on your phone are talking to Apple (and other 3rd parties) anyways, that this might not even matter?

Although the FBI seems to be not very happy about this (if it's not just "for show" that is)[1]. The FBI is using the age-old "Save/Protect the children" argument, literally.

[1] [http://www.washingtonpost.com/business/technology/2014/09/25...](http://www.washingtonpost.com/business/technology/2014/09/25/68c4e08e-4344-11e4-9a15-137aa0153527_story.html)

<comment><USER48> Never mind that none of this matters if you have unlocked the phone and it's on (default protection policy is protect until first unlock, which happens right after turnup). That's gotta be 99.9% of cases. Once the police or apple have a locked phone, all bets are off. Apple can just install an app remotely that gets them past the lockscreen, and unless this is from a cold boot, you have access to all apps and all data. This includes access to e.g. The logs of any configured skype session, the company mails ...

Add to that the usual closed software problems. Apple says they don't have a specific backdoor anymore (!), and they won't let you audit anything.

<comment><USER4> >> Apple says they don't have a specific backdoor anymore (!), and they won't let you audit anything.

Yes. Its amazing to me how eager some people are to take a corporation's spokepeople at their word.

</comment></comment></comment></comment><comment><USER49> Dont worry, the NSA can.

</comment><comment><USER50> All the criticisms I've yet seen of Apple's iMessage security comes down to "yes it's probably completely locked down now and for all historical messages, but here's this obscure way they could open it up for messages in the future therefore it's not secure".

Well duh! It's their software. Of course they could backdoor it in future, such as if required to by the government. That's true of any software. Apple are asserting that right now there are no such backdoors and iMessages are secure. I've not seen any credible argument that this is not the case other thst "maybe they're lying". Ok. What's the alternative? Run everything through OpenSSL? That didn't worm out do well. Maybe we should run everything on Linux using Bash scripts. Oops again!

Maybe Apple are lying. Maybe they will sell us all out. But if they do these things always have a tendency to come out in the open eventually. So far they've had a pretty good track record of being on the level. In the end it's tfag reputation, and their appreciation of its value, that is the best and really the only guarantee we have, as with anyone else we rely on.</comment>


70mm version of 2OO1: A Space Odyssey to be shown in Cannes and some US theaters - <AUTHOR> https://www.businesswire.com/news/home/20180328006021/en/Warner-Bros.-Pictures-Celebrates-50-Years-Stanley <comment><AUTHOR> Is anybody in the know whether they'll actually show the 70mm print at the Cannes Classics on May 12 on that open-air screen near the ocean? Don't get me wrong, I'd love to sit down with Christopher Nolan and members of the Kubrick family in a beach chair burying me feet in the warm sand.

But it seems to me that 2OO1 deserves a less distracting environment.</comment>


Ask HN: Which clojure implimentation is primary? - <AUTHOR>

Clojure runs on CLR, JVM and JS. Which implimentation is meant to be primary? Does clojure suffers from 'implimentation switch'? (ie Primary Development like libraries, compiler optimizations and documenting shifts by the mood of the community)<p>For example, imagine, today the main development implimentation (supported by the community) is CLR, I start learning/using that implimentation, and suddenly in a matter of days the community switches to Javascript and start implimenting new technology in it. There are only few people mantaining the CLR version. Now after some days, I not only have to change my codebase, but also my platform.... <comment><USER2> Rich Hickey started out with simultaneous CLR and JVM implementations, then dropped the former when he realized he was slowing down the development of the language by half. Since then the CLR version has been picked up by others, and although I'm just getting back into the Clojure community it sure looks like ClojureScript is getting a lot of respect, there is a very minor breaking change in the JVM version 1.4 for compatibility with ClojureScript (very minor in that if you're ... wild enough to name record fields with a leading dash (e.g. "-a") one syntax for accessing them no longer works, which allows something else useful in ClojureScript and JVM Clojure 1.4).

If you want the unquestioned primary one, it's the JVM one found at <http://clojure.org> and I don't see that changing for a very long time unless Oracle goes insane in very unexpected ways (not likely, seeing as the first new JVM version they put out adds some support for dynamic languages).

<comment><AUTHOR> Can clojurescript become a primary clojure implimentation?</comment></comment>


This week should put the nail in the coffin for 'both sides' journalism - <AUTHOR> https://www.washingtonpost.com/lifestyle/style/this-week-should-put-the-nail-in-the-coffin-for-both-sides-journalism/2017/08/16/77c6668a-8292-11e7-b359-15a3617c767b_story.html <comment><USER2> ..if the biased media have their way.</comment>


ZFS on Linux 0.8.0 - <AUTHOR> https://github.com/zfsonlinux/zfs/releases/tag/zfs-0.8.0 <comment><USER2> Finally native encryption! Might still be a bit of a dance to boot - but I'd much rather have small ext3 /boot and let zfs do disk/volume/encryption/compression on the rest. Oh, and while swap on a zvol is possible - I regret setting that up on my laptop. Traditional encrypted swap makes more sense for hibernation.

In ideal world, zfs would do all, and we'd boot straight in - but as far as I can figure out that'll require a new bootloader project. And I'm not sure how I feel about (full) zfs support in my bootloader anyway.

<comment><USER3> I currently have all my ZFS drives on top of LUKS for my storage disks. I don't have the disks to shuffle things around at this point, but when I need to expand, I'm sure I'll use the native encryption on new disks! This is pretty big.

On my boot volume, I run full disk encryption (luks+ext4 for everything including /boot). Grub has built-in support for luks type 1 (do not use luks version 2! Grub can't unlock those yet. I learned that the hard way :-P).

If you have a signed Grub EFI loader, remove the default secure boot keys and add in just the CA/certs for your system and password your BIOS/setup, you have the potential for a very secure system (ignoring the Intel/AMD management systems that are difficult or impossible to disable).

<comment><USER4> > If you have a signed Grub EFI loader, remove the default secure boot keys > and add in just the CA/certs for your system and password your BIOS/setup, > you have the potential for a very secure system (ignoring the Intel/AMD > management systems that are difficult or impossible to disable).

Or just dump Grub altogether and boot kernel directly as an UEFI image. No need for middle-man!

(Instructions vary by distro but see this for example: [https://wiki.gentoo.org/wiki/EFI_stub_kernel](https://wiki.gentoo.org/wiki/EFI_stub_kernel))

<comment><USER2> But then you're loading the kernel from unencrypted fat32 partition?

<comment><USER4> If it's signed with Secure Boot keys it's no different for loading signed Grub image. Grub would also need to be unencrypted to work.

As for signing kernel: [https://github.com/andreyv/sbupdate](https://github.com/andreyv/sbupdate)

</comment></comment></comment></comment></comment><comment><USER5> We at Datto [1] are all very proud of our very own Tom Caputi and all the hard work he and the ZFS team have poured into the encryption at rest feature. Well done and thank you for an amazing feature!

Also, we're hiring [2] ;-)

[1] [https://www.datto.com/](https://www.datto.com/)

[2] [https://www.datto.com/careers/job- board](https://www.datto.com/careers/job-board), esp. [https://www.datto.com/careers/job- board/post/1639738](https://www.datto.com/careers/job-board/post/1639738)

</comment><comment><USER6> I didn't know sequential scrub was in this release. Really excited about that one.

<comment><USER7> Why is that? I've not read up on that particular feature.

<comment><USER8> Sequential scrub turns "let's read all the blocks in the order we see them in the metadata" into "let's separate this into a read and a dispatch phase, so we can group things we dispatch into sequential regions and make spinning disks less sad at the amount of random IO needed".

It's quite a dramatic improvement for pools on hard drives.

<comment><USER7> Oh nice. Thank you for the explanation.

Does that have an impact on how long a scrub takes? I've always loved the ability to do online scrubs but they can take a long time

<comment><USER8> Very much so. Spinning disks are bad at seeking randomly, and turning lots of random IOs into a smaller number of relatively sequential IOs is a substantial win.

</comment></comment></comment></comment></comment><comment><USER9> The his is huge: directed-IO and trim being sent to underlying drives. This is a massive update. Oh and encryption to boot!

</comment><comment><USER10> Yes! 0.8 is a pretty amazing release, can't wait to run it on Proxmox.

<comment><USER11> Me as well :-)

</comment></comment><comment><USER12> Hmmm I wonder why they don't support SIMD instructions on 5.x kernels. I couldn't find any information on what might have changed that would cause that to be an issue.

<comment><USER13> Linux 5.0 changed exports that ZFS needed to be GPL-only: [https://marc.info/?l=linux- kernel&m=154714516832389&w=2](https://marc.info/?l=linux- kernel&m=154714516832389&w=2)

<comment><USER14> How does the exports work that the ZFS folks cannot compile their code with the SIMD instructions? Is there some docs on how this works?

<comment><USER15> The x86-64 FPU state is quite large so normally the user task's FPU state is only saved/restored on a task switch.

This means that if kernel code wants to use the FPU (which includes the SIMD instructions), it has to explicitly request access and return it when it's done. The functions that do that are the exports being referred to here.

</comment></comment></comment></comment><comment><USER16> This is big: it finally mainlines the native encryption work.

<comment><USER17> And TRIM for SSDs.

I have been running RCs for some time and both TRIM and encryption have worked fine.

<comment><USER18> Do you know/notice the performance difference from encryption?

<comment><USER17> I haven't measured it, but it will use AES-NI instructions when available.

I don't notice a difference in daily use.

</comment></comment></comment></comment><comment><USER19> Sounds really good. Particularly looking forward to native encryption and TRIM.

I couldn't see it on the list, but I believe I've heard it mentioned before... Right now ZoL maintains its own cache, ARC and other things, besides what the Linux-kernel already provides, causing excess RAM usage.

Any news on that situation improving?

<comment><USER20> >Any news on that situation improving?

This situation "improving" would be a performance regression, an afaik, no one is really looking to do anything about it. Managing its own caches are a feature, not a bug.

That memory is freeable if an application needs it so there's no harm in it being used, either.

<comment><USER21> It's still not great. Linux native caching keeps fighting with the ZFS cache and it's not quite as freeable as native cache. If you try to launch some applications that allocates big chunks of memory quickly, it may fail due to ZFS not freeing its memory fast enough. I had this issue before limiting the max ZFS cache size. If ZFS could integrate the caching better with Linux it would be perfect to me.

<comment><USER22> How does FreeBSD handles it?

</comment></comment></comment></comment><comment><USER7> Excellent. I have been running RC5 for a week for compatibility with a feature in FreeBSD 12's build of OpenZFS. So I'll be building this release tonight.

</comment><comment><USER23> Great work. Finally no more LUKS inside my ZVOLs :)

</comment><comment><USER24> Any word on when zstd support will get added? Feels like I've been hearing about it for two years now.

<comment><USER25> There is a pull request for it, but seems like it's post-0.8.0:

[https://github.com/zfsonlinux/zfs/pull/8044](https://github.com/zfsonlinux/zfs/pull/8044)

</comment></comment><comment><USER26> Have releases generally been solid? Is this okay to install on my server today, or is it like Ubuntu, where you're supposed to wait for the first point release because .0 is actually a bit of a beta?

<comment><USER27> There was a data corruption issue in recent history ( [https://github.com/zfsonlinux/zfs/issues/7401](https://github.com/zfsonlinux/zfs/issues/7401)), but otherwise I've found ZoL releases to be very stable.

</comment></comment><comment><USER28> Debian Buster packages when?

<comment><USER8> Since [1] packages through -rc4 and [2] already has rc5 and 0.8 final in the upstream branches, I would suspect you'll be able to build a package for buster Soon(tm), though I do not personally know how creation of -backports works for testing during a freeze.

[1] - [https://packages.debian.org/source/experimental/zfs- linux](https://packages.debian.org/source/experimental/zfs-linux)

[2] - [https://salsa.debian.org/zfsonlinux- team/zfs](https://salsa.debian.org/zfsonlinux-team/zfs)

</comment></comment><comment><USER29> When will this be part of FreeBSD?</comment>


Collection of web APIs - <AUTHOR> http://www.programmableweb.com/apis <comment><USER2> I'm noticing that people keep on posting data and API sites, and since I'm in that business as well, here's my sales pitch.

If anyone is interested in bank rate data, we offer rate API data feeds for CDs, Savings, Checking, Mortgage, Credit Cards, as well as National averages.

<http://www.mybanktracker.com/services>

</comment><comment><USER3> I was looking for something like this the other day and couldn't find it.

This is awesome.</comment>


Show HN: Dope personalized dashboards off your Apple Health & Google Fit data - <AUTHOR> http://www.personalytics.me <comment><AUTHOR> We are happy to share that we have finally launched Personalytics, the world's first AI wellness coach. It is available at www.personalytics.me

Would appreciate if you try or provide constructive feedback and ideas!

We all know we need to exercise, sleep well, and take care of our mental health. Yet we often fall into bad habits without even realizing it. According to Cornell's research, people spend 90% of their waking life on autopilot. There is good news though: tons of scientific evidence shows that the moment we become aware of our habits, wellness automatically improves. Hence, we built a smart wellness coach to track and make sense of data on things like sleep, fitness, productivity, weight, all in one place. Kwirki, our AI coach, keeps you aware of your wellness habits through personalized insights and dashboards.

What are the benefits?

1\. Personal AI wellness assistant that connects to any wearable you use

2\. All wellness data collected and interpreted in one place

3\. 500+ daily wellness insights

4\. Weekly personalized dashboards packed with insights to track your progress

Delegate your wellness to AI right now at [http://www.personalytics.me](http://www.personalytics.me) and become the master of your body and mind :)

<comment><USER2> Couple of points

1\. Where are your legal docs?

2\. First? I didn't even have to finish typing and hit search to see there are many many apps which purport to use "ai" as a wellness coach

<comment><AUTHOR> Thank you for checking us out :)</comment></comment></comment>


Ask HN: Why is ipq.co so fast? - <AUTHOR>

I've discovered http://ipq.co here, and I'm amazed by how fast the DNS record is available throught my company's DNS server. How is it possible? I've always been told that DNS propagation could took from 24h to 72h...I'd be really glad to know the trick to such blazzing fast updates! <comment><USER2> Two reasons:

\- If the domain is totally new your company's DNS server will not have it in cache and will query the authoritative server (probably what happened here)

\- If the domain already exists in your company's DNS server cache it needs to have a TTL set, which basically defines how long it can be in cache before the original authoritative server is queried again (see <http://en.wikipedia.org/wiki/Time_to_live#DNS_records>). If this is set low the cache is less effective but DNS changes propagate faster.

<comment><AUTHOR> With ipq.co the subdomain is either new or already existing (and not editable). That explains everything, thanks!</comment></comment>


Revolution OS [video] - <AUTHOR> http://video.google.com/videoplay?docid=7707585592627775409#

<comment><USER2> Worth watching for those who have even a slight interest in GNU or Linux.

It is however very left wing, and fails to mention any flavor of BSD but you can't have it all.

<comment><USER3> In this film, Richard Stallman presents his ideas very directly in interviews, so any left-wing bias is not really "hidden." This is a good way to learn about his views.

<comment><USER2> I meant more towards the very anti large non free software business messages that are in it.

For example (all microsoft examples here off the top of my head)

Raymond giving the thousand yard stare at Microsoft exec Bill Gates open letter Richard talking about MS being a small player initially The Microsoft free software refund meeting

All were made large closed source businesses look like the enemy. So the show is very biased especially towards Microsoft. Richard is indeed very open but the movie can be seen as a propaganda piece rather then purely factual.

<comment><USER4> So being against huge corporations is a left wing thing now? Was Adam Smith left wing?

<comment><USER3> Americans and Europeans mean different things by "left wing" and "right wing." In Europe, the spectrum goes from socialists to fascists. In America, the spectrum is much more narrow. It goes from a highly regulated state to a highly deregulated state, speaking economically. So in America, being against huge corporations is basically a left wing thing.

<comment><USER4> I'm American myself, it's just that this viewing huge mega corps as a good thing by the right feels relatively new.

</comment></comment></comment></comment></comment></comment><comment><USER5> Pretty interesting.

I actually think the most interesting thing is what happened to VA after the documentary. They've gone from a servers company to thinkgeek.com - weird.

Here is a pretty good story about it: <http://news.cnet.com/8301-13505_3-10413589-16.html>

</comment><comment><USER6> I love the scene at the end where Stallman is going on one of his gnu rants on stage, and linus brings his kids out completely upstaging him.

This is one of my favorite documentaries, would definitely like to see a sequel.

<comment><USER7> Yeah that scene was pretty good. Linus comes across as a really good guy. Stallman (as usual) comes across (to me anyway) as slightly unhinged and bitter.

</comment></comment><comment><USER8> I actually own this on DVD and watch it every now and again, pretty cool documentary on the history of GNU/Linux

</comment><comment><USER9> Wow, ESR. Haven't heard from him in a while.

Someone should write an updated counter-point to the cathedral and the bazaar. A lot of it's theories seem dated nowadays.

</comment><comment><USER10> The background music and dramatic reading of Gate's Open Letter to Hobbyist's was annoying.

<comment><USER11> I couldn't stop thinking the same thing.

What killed me was the Free Software Song live performance at the end. These are late 90's nerds at their nerdiest.

</comment></comment><comment><USER12> FYI, you can stream this from Netflix in high quality. Watched it on my friends Xbox the other day.

</comment><comment><USER13> The very first week in my Operating Systems class the assignment was to watch this video and write a report about it.

It was only once I dug deeper I realized how absolutely insane Richard Stallman is.

<comment> loup-vaillant Could you define "insane", please? I've read the "Free Software, Free Society"[1] compilation, and Stallman appeared to me as very balanced and cautious (at least when it comes to his political views).

[1]: <http://www.gnu.org/philosophy/fsfs/rms-essays.pdf>

</comment></comment><comment><USER14> great documentary i thought ... interesting to see the press it got in the beginning, i did not realize how mainstream linux was at some point</comment>


Don't assign work to developers - <AUTHOR> http://blog.in-sight.io/dont-assign-work-to-developers/

<comment><USER2> I can't really take a blog seriously when the first sentence shows that none of the article was given a second read through.

>Directly assign work to developers instead of letting them choose whatever we they want to work on next from the current iteration may look like a good idea at first.

"whatever we they want" \-- Fixed

>incompetent. when in fact,

Missed capitalization. -- Still not fixed

>this whole software — not just the accounting features — but the software as a whole.

'this' should probably be 'the' because 'this' is never specified. What is 'this' software referring to?

E: You _may_ want to replace most instances of 'might' with 'may'. 'Might' typically implies a lower chance of happening than 'may'. It won't drastically change the meaning of any of the sentences, but it will sound a bit more optimistic. It currently implies that there is a large amount of doubt that anyone will succeed because they _might_ do better instead of _may_ do better.

eg.

I _might_ reach the peak of Mt. Everest.

I _may_ go swimming tonight.

This isn't a concrete grammar rule. [0] But if you're trying to sell people on this being a good idea, you may want to show confidence that it _may_ improve things rather than it _might_ improve things.

[0] [http://lingohelp.com/english/may- might/](http://lingohelp.com/english/may-might/)</comment>


Sky Book - <AUTHOR> https://play.google.com/store/apps/details?id=com.kalisoft.skybook <comment><AUTHOR> Sky Book safely keeps your notes, reminders, important & essential information in the cloud. So, you never lose your important notes and you can access them anywhere and on any other android device.

<comment><USER2> It looks very well designed. How does this compare with Google Keep?</comment></comment>


Dropbox DMCA takedown on personal folders - <AUTHOR> https://twitter.com/darrellwhitelaw/status/450096476060794880/photo/1 <comment><USER2> Looks like the OP was asked a few times if the files were shared publicly or not. I think that's the key piece of information about this.

If it was copyrighted material that he shared/linked to publicly, then it makes sense. If, however, it was private files that he hadn't shared with anyone else, well, then this is a _HUGE_ deal.

<comment><USER3> Yes, it looks like OP isn't presenting the whole story. The DMCA filing party would have to provide the URL (of the public/shared folder) containing the copyrighted material to dropbox for takedown. I don't think they can just request dropbox to scan private folders to check for copyrighted content.

<comment><USER4> They'd have to provide the URL of _some_ public folder containing the copyrighted material, but that's probably sufficient to get every identical file taken down including ones in private folders.

<comment><USER3> Yes it is sufficient and doable but the question is will dropbox do it? How will they even identify whether I own or have the license to use the files I have in my private folder. If I just keep my purchased ebooks in a dropbox (private) folder and a public folder (belonging to someone else) containing some of the same ebooks are flagged, why should I be affected?

<comment><USER4> If they don't want to meet the same fate as MegaUpload, Dropbox are certainly going to take down all copies.

<comment><USER5> In other words, you can't use Dropbox for any copyrighted content, even that which you _own_ and are just storing there _privately_?

That doesn't even make sense... but then again, much of copyright law doesn't either.

</comment></comment></comment></comment></comment></comment><comment><USER6> Dropbox help explicitly refers only to shared files/public links wrt copyright policy: [https://www.dropbox.com/help/210/en](https://www.dropbox.com/help/210/en)

edit: on further reading of his tweets, it appears that he shared link to the file with another person. So while Dropbox might be overstepping a bit, imho it seems that their action was justified (assuming that the DMCA complaint was originally justified).

edit2: Dropbox response [https://twitter.com/dropbox_support/statuses/450176566375366...](https://twitter.com/dropbox_support/statuses/450176566375366656)

<comment><USER7> @dropbox_support claims content removed under DMCA only affects share-links.

@darrellwhitelaw replies that's what he meant, only sharing is disabled.

Good find, that clarifies a lot.

</comment></comment><comment><USER8> One possibility is that Dropbox deduplicate files (they almost certainly do), and somebody else had a public copy of the same file, and that was given a DMCA takedown, which now also applies to his copy since it's the same file even though it's private.

<comment><USER9> I should hope it doesn't work that way, because under section 117 of the Copyright Act I'm allowed to keep an archival copy. [0]

[0] [http://www.copyright.gov/help/faq/faq- digital.html](http://www.copyright.gov/help/faq/faq-digital.html)

<comment><USER10> There is nothing in dropbox's message suggesting he cannot upload or access archival copies. It says they got a dmca notice so they disabled sharing on some of them.

This is either a bug on dropbox where the message shows to anyone having some flagged file(s), or he was sharing copyrighted content and conveniently emptied the folder before taking the screen capture to paint dropbox in a worse light.

</comment></comment></comment><comment><USER11> It's important to note: once you add a link it can happen at any time. Removing the link doesn't fix it (i.e. deleting & creating a new folder). The folder path/name is permanently flagged and thus unusable even for personal content.

</comment><comment><USER12> I randomly ran into someone working for the movie association in Hong Kong and he told me that they regularly scan forums looking for links to copyrighted materials. From time to time they do find links to Dropbox and Google Drive, and they send takedown notices when that happens.

</comment><comment><USER13> Even if this isn't as nefarious as the title suggests, it's still an excellent reason to drop dropbox. Have you tried owncloud? That's what I use and it's perfect for escaping stuff like this as well as dropbox's new criminal terms of service. Just in case there's anyone who doesn't know, dropbox recently changed its terms of service to circumvent consumer protection laws by requiring its users to forego common rights under the law, a common tactic traitors are using these days (Microsoft also did that on Xbox live for example). So please take the opportunity to learn about owncloud and ditch dropbox as soon as possible.

</comment><comment><USER14> The text of the warning says:

"Certain files in this folder cannot be shared due to a takedown request with the DMCA"

I interpret that as he has some copyrighted files in his private folder which he is trying to make shared/public. Perhaps dropbox has previously gotten a takedown request for those files (when shared by some other user), and to comply with the request is preventing anyone else from sharing the files in the future.

<comment><USER15> That's not how DMCA works. That's how some of the bigger copyright organizations (RIAA for example) want it to work.

Besides, what might be copyright infringement to one user might be legitimate usage to another. For example, you might have an illegal copy of an ebook in your folder, but I have the same copy, but mine was paid for. Should I lose access to mine? OReilly books don't have DRM, so it's possible it could happen.

<comment><USER6> > Besides, what might be copyright infringement to one user might be > legitimate usage to another

While technically true, I think it is very rare that a file is DMCAd for one user while another is _sharing_ it legitimately. Rare enough that a trip to customer service is warranted.

> For example, you might have an illegal copy of an ebook in your folder, but > I have the same copy, but mine was paid for. Should I lose access to mine?

Note that the discussion here revolves around sharing, not having personal access. So while you should (and would with Dropboxs current system) retain your own access to the files, you shouldn't be able to share it, which seems reasonable to me.

<comment><USER16> Again, that's not the structure of the law. The DMCA requires that a takedown notice specify the specific content. Both the data itself and the usage have to be identified, there's no notion in the law of forbidding access to specific "files" by their data alone.

<comment><USER6> Yes, Dropbox is working pre-emptively on their own initiative here.

The message is quite cleverly constructed, as it doesn't actually say that there is a DMCA takedown request against the file (because there isn't). It just says that there has been a takedown request sometime, possibly(probably) against some other file/url.

</comment></comment></comment></comment></comment><comment><USER17> Here's a hacking opportunity - obfuscate files prior to Dropbox sync so they fail at their duplicate detection.

<comment><USER18> no need for obfuscation.

Respect Dropbox TOS and your files will not be deleted.

Share some copyrighted material and deal with the consequences.

By the way you can encrypt files before sending them to the cloud, but in order to share them with a third party you'd have to give your keys, which makes little sense.

<comment><USER19> Makes perfect sense to me if you don't trust your host not to report you. Keys are small enough to just send in a private chat rather than hosted alongside the encrypted file.

<comment><USER20> > if you don't trust your host not to report you

Don't do illegal shit on Dropbox; problem solved.

<comment><USER21> Laws are numerous and vary from place to place. Such simplistic advice can never capture the nuances of every "right" decision everywhere.

</comment></comment></comment></comment></comment><comment><USER7> It may be time to add a TrueCrypt volume to Dropbox...

<comment><USER22> how would you avoid having the entire volume file being uploaded/downloaded when you are just browsing it (access time changing) or changing just a small file ?

let's say you have a TC volume of 5GB that contains your personal notes in txt files. You edit one txt file and Dropbox will have to synchronize 5GB of data.

I prefer encrypting files one by one, e.g. using Cloudfogger.

<comment><USER23> IIRC, the delta between two slightly different copies of the same TC container is not the same size as the entire container. I'm actually not sure that TC is designed to be used this way, since it gives away information about what is being changed, when, and how much.</comment></comment></comment>