Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment How long until the total surveillance state ... (Score 1) 208

So, we already have the FBI/NSA/CIA/etc using national security letters (or maybe even just plain requests) to get your location data from your cellphone because "you've shared" your location with a 3rd party (e.g. - Google maps). Therefore, that data is no longer "yours" and instead belongs to the business and is largely free to be shared with whomever else they want at their discretion.

How long before a similar logic is applied to your "always on" microphone tracking every word you say? I guess we'll just have to trust these giant corporations to protect the privacy of their users rather than comply with the desires of big government ......

Orwell was right about Big Brother but we've chosen to do it to ourselves (through our cellphones).

Comment Re:Books, Music, and APIs (Score 1) 405

"I would argue that an API itself is not a main design component of well-written code ..."

And I would strongly disagree. API design is one of the hardest and most valuable things software engineers do: determining the best places and ways to expose appropriate functionality so that it is most useful to others (including yourself).

Look at the design of C++'s standard library APIs (part of it being the former STL). Then compare that to some half-ass collections interface (e.g. - early versions of collections in Java). You are claiming that there is nothing worthy of legal protection in the design of those far superior C++ interfaces. That they are merely some necessary functional bits to invoke the (truly valuable) code that sits behind them.

I'm saying, yes, they are functional, but they are very much more as well. They represent the design decisions of the best *WAY* to facilitate, for example, manipulating in-memory data structures. To easily allow subsequences of one collection to be used while operating on another collection, perhaps of even a fundamentally different type. And so on. There is a ton of value in the design of those APIs. I would argue much more than in any specific code that implements the backing functions themselves. I'm not sure if that value is what you meant by "artistic expression," but good API design absolutely is an art that is hugely valuable and worthy of legal protection.

Comment Re:Books, Music, and APIs (Score 1) 405

"One could reasonably argue that a header file collects the declarations from source code, and that the real creative work is the source code itself."

This kind of argues that the way you organize your code has no value. Or, that extracting a main design component of your code -- its organization -- renders that design no longer protectable (but it would have been if you didn't create a header?).

I see no reason to believe that -- quite the opposite in fact. In particular, I see no reason why to believe that lines within some function are more worthy of legal protection than the way you designed invoking that code in the first place. The API of something is often considerably more important and valuable than any particular implementation of it.

Comment You should be able to copyright APIs ... (Score 1) 405

Google argues that all the design work that people put into figuring out the best APIs for their software systems cannot be protected by copyright. That all that design activity is basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.

Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that Bjarne's team instead did all that design work only for their own company's use and never intended it for general consumption or use outside their company.

The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are "just" APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.

That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.

Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.

Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration back to you -- is an entirely different proposition. Authors should absolutely retain intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit or not.

Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that appears in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use. The same sort of logic would apply here too.

Comment Re:The API _is_ the semantics of language (Score 1) 405

"... the API is just a functional (non-creative) description of the correct way to interact with the code."

Google argues that all the design work that people put into figuring out the best APIs for their systems cannot be protected by copyright. That all that design activity is "not creative," in your words, basically worthless and not worthy of legal protection. I really have no clue how this became the predominant belief amongst software people. Convenience? Stealing someone else's API design is easier than figuring one out yourself, I guess.

Look at the design of the C++ language and its standard library. Think about the huge amounts of effort that Bjarne Stroustrup (and others) put into making the language and all of its API pieces fit together in the best way in their view. Now, imagine that he instead did all that design work only for his own company's use and never intended it for general consumption or use outside his company.

The arguments put forward by Google, and many others, are that if all those complicated, interconnected APIs somehow leaked out onto the internet (e.g. - a disgruntled employee surreptitiously posted them somewhere without permission), then everyone else would be legally free to copy them verbatim and reimplement the backing code without a single bit of permission nor consideration going back to Bjarne nor his company. They are APIs that aren't copyrightable and almost surely not subject to patent protection. Google's approach values all that API design work as entirely worthless and not intellectual property in the least.

That's ridiculous. API design is a HUGE part of software design and development. I'd argue that it is often more important and valuable than any particular backing implementation of the API.

Ok, now imagine a bit different C++ scenario. Stroustrup really likes his C++ language and wants to publish about it, including his specific API design. Does the mere fact that he voluntarily revealed his API to the public (without any license but with a copyright claim), now allow everyone to run off and copy it verbatim again without permission nor consideration back to him? Again, that does seem to be Google's argument and it seems bonkers to me.

Arguing, as the EFF does, that open and free APIs are a good thing that facilitate competition, wide adoption, superior implementations, etc. is one thing. But arguing that all APIs are inherently open and cannot be protected as intellectual property -- that anyone can legally come along and copy verbatim the huge, complicated class hierarchy and interfaces that you designed for your software without your permission nor consideration -- is an entirely different proposition. Authors should absolutely retain the intellectual property rights to their specific APIs. They can license them or put them in the public domain as they see fit.

Now, the obvious criticism of my stance is that what is to prevent someone from putting and enforcing a copyright on something absurdly simple like C's strlen() function or something similar? Would we have the equivalent of patent trolls trying to extract money from anyone who codes? My answer to that is it would be up to the US Copyright Office and the courts to determine what is fair-use and what is simply too trivial to copyright. For example, a book author's copyright does not give them the right to go and sue anyone who happens to use a sentence that happens to appear in their book, but it does allow them to sue people who reproduce significant sections of their book that go beyond fair-use.

Comment Re:BULL S^%$ (Score 1) 405

Yes, if attackers can successfully disseminate software that looks legitimate (e.g. - signed by Apple certificates), then that could allow them to install "keyloggers" or similar that could allow them to skirt around most any security codes. They'd just have to wait until the user enters their password again to unlock whatever secured files there are and then they could leak the contents or the password could later on be used to access the data as needed.

Still, that's a far more difficult hack than simply plugging into the phone and being able to easily brute force defeat any security there.

If you secure the data using AES-128 or AES-256 and the owner uses a decent password, then the only way to get at that data today is through some form of keylogging that subsequently captures the owner accessing their data again.

Comment Re:I don't get it ... (Score 1) 389

The keyspace for several common symmetric encryption schemes (e.g. - AES-256) is on the order of 2^256. So, brute force attacks aren't even possible on them because there isn't enough energy in the universe to try all combinations before the heat death of the universe. You need to find some kind of flaw to drastically reduce the search space first.

http://www.eetimes.com/documen...

Comment Re:I don't get it ... (Score 1) 389

So, Apple has a unique ability to subvert older generations of their iPhone through software signed by them. Then, yeah, the govt. absolutely does have the right to invoke Apple's special capabilities to conduct a lawful search warrant. All of this points to the wisdom of designing such systems so that even Apple can't break them. Then in the future they can claim they have no special capabilities not available to the govt already. This case is a legacy cost for doing half-assed security in the past. Oh well, lesson learned.

Comment Re:Apple should take the next step (Score 1) 389

I definitely agree with that, but if just changing the OS allows a 3rd party to decrypt the data, then the security is still horribly broken. For the data to be secure, Apple, the govt., whomever, should be able to access the full contents of the phone, know all the algorithms involved, etc., and still not be able to decrypt the data. If the user used too short of a password that allows it to be brute forced, then that's their fault.

Comment Re:I don't get it ... (Score 1) 389

It sounds like what you are driving at is that the data itself it not well secured really at all. If you can get a copy of the data and successfully brute force attack it, then that's user error for not having a long enough random-ish password to encrypt the data. For the data to be truly secure, Apple, the govt. whomever should be able to fully access the entire contents of the phone, know what algorithms are being used and still not be able to decrypt the data without knowing the encryption password and brute forcing it should be prohibitively expensive.

Slashdot Top Deals

When it is not necessary to make a decision, it is necessary not to make a decision.

Working...