Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:Serious question for the Linux community (Score 1) 367

It has been reported that it accesses /ect/password

Contrary to popular assumptions, /etc/passwd doesn't contain any passwords these days. What it does contain is a mapping of UIDs to usernames. This means that even such benign utilities such as ls access /etc/passwd. That's how ls -l can show you usernames instead of UIDs. Skype can't get your passwords from /etc/passwd and there are some very ordinary reasons for it to be accessing /etc/passwd.

Comment Re:It's not REST (Score 1) 161

The point you were trying to make is that links being important is actually something that came later, and you tried to argue this point by saying you read his early work and blogs and it wasn't mentioned.

I am pointing out that it was a central theme right from day one. It was mentioned in his thesis published in 2000, and it's also ludicrous once you recognise the fact that REST is a description of the architecture of the WWW, which clearly revolves around links. It's not plausible that you could ever understand REST but not understand how important links are to it.

You didn't read his work. You admit you didn't read his thesis, and although you claim you read blogs by him at the time (2004 or so), he didn't start blogging until 2008. You are now citing some webpage you found by googling REST, but you conveniently don't mention which one, why it would contradict the things we know he has been saying from 2000 onwards, or why you think reading some webpage you found with Google counts as actually reading the relevant material.

REST has a precise definition that includes linking, just as "Java" has a precise definition that is distinct from "JavaScript", despite a lot of people misunderstanding that. You say that words change, but you are helping to cause the change whenever you mislabel something as REST, so to hold your hands up to say that you can't do anything about it rings as hollow as your claims to have read the material at the time.

Comment Re:It's not REST (Score 1) 161

This isn't just "the people that work next to me".

I'm not about to tell all the third party APIs I use daily that their REST api's aren't REST. It's too much work.

Here is what you originally said:

When I hear a colleague say REST it usually means what you have in your example. So much so, that it would take to much time and effort to correct everyone.

We weren't talking about the whole world fucking up, we were talking about your colleagues not knowing what they were talking about. To which my response is: tell them they are fucking up so they can stop fucking up. "I can't change the world" isn't a response to that.

I didn't read his thesis at the time.

Again, this is what you originally said:

I remember reading Fielding's blogs and work when REST was becoming a popular term. The idea of hypertext links was not as prevelent. It was there with some mention to atom rss and the likes

If it mentioned Atom, then you're talking about years after he published his thesis. You say you remember reading his work, but you clearly didn't read it despite it being available at the time. Just some nebulous "blogs" (that couldn't have existed because he didn't start blogging until years afterwards).

Comment Re:It's not REST (Score 1) 161

I remember reading Fielding's blogs and work when REST was becoming a popular term. The idea of hypertext links was not as prevelent. It was there with some mention to atom rss and the likes, but it wasn't the main point of REST.

Hypermedia as the engine of application state is listed as one of the four fundamental constraints of REST in his thesis. It's a central part of REST. It wasn't retrofitted later. If you missed it, you weren't paying attention. REST is essentially a description of the architectural style of the WWW. And you're saying that the idea of hypertext links wasn't prevalent from the start? What WWW have you been using?

When I hear a colleague say REST it usually means what you have in your example.

Then you work with people who don't know what they are talking about. You can either point that out to them so that they can fix their ignorance, or you can let them labour under the misapprehension that they know what they are doing. Do them a favour and point it out to them. Or at the very least, ask whomever is in charge of documentation not to refer to it as REST.

REST is not some nebulous term where you can argue your case. It's got a specific meaning. Mislabelling any old HTTP web service as REST is like confusing Java with JavaScript - something nobody who claims to know what they are talking about should be mixing up.

Comment It's not REST (Score 1) 161

If you look at that API and you think it's REST, then you don't know what REST is. Here's Roy Fielding's blog post where he points out that these types of APIs aren't REST. Roy Fielding is the guy that described this architectural style and coined the term "REST" in the first place.

Here's one example: You perform a GET request at /vehicles to obtain a list of vehicles. These vehicles take the form of JSON data, including an id attribute. If you want to perform operations on a vehicle, you need to construct URLs of the form /vehicles/{id}/.... That is not REST.

REST is hypertext driven. It revolves around content types, not manual URI construction. If that were a RESTful API, it would describe a vehicle list media type, and that media type would contain URIs, not IDs that you have to construct new URIs from using out of band knowledge. Their approach is like if every web browser was hard-coded to find articles at /articles instead of using links. It's dumb.

This misunderstanding is far too common. Don't guess at what REST is when you construct an API like these guys did, look it up for yourself.

Comment Yup (Score 1) 176

This just reinforces what I said the other day about Apple's App Store approval process really making a difference to the quality of the applications available for iOS.

Apple have a rule in their guidelines:

2.20 Developers "spamming" the App Store with many versions of similar Apps will be removed from the iOS Developer Program

Comment Re:That didn't work in an app (Score 1) 206

Then why not allow outside markets and advertise theirs as the premium one?

I'm responding to what you said here:

Either way security problems will exist and pretending that their app auditing is anything more than a justification for a walled garden is simply burying your head in the sand.

You were arguing that the promotion of a walled garden was the sole purpose for the approval process for the App Store. That's a silly thing to say, and I explained why. You've now changed your argument to something else - that Apple are enforcing the App Store as the sole source of applications to build a walled garden. That's a different argument entirely, and doesn't make what you said earlier any less silly.

Comment Re:That didn't work in an app (Score 1) 206

Either way security problems will exist and pretending that their app auditing is anything more than a justification for a walled garden is simply burying your head in the sand.

The walled garden is probably one reason for the approval process, but it's certainly not the only one. Apple seem genuinely motivated to use it to raise the quality of the end-user experience.

Here's one example: a few years ago, developers were complaining that Apple was rejecting their apps for having an icon of a phone in their app. It didn't make sense - why would Apple object to that? It wasn't an icon depicting a competing phone. It wasn't infringing on their trademarks or copyrights. People couldn't figure it out.

Then, a short while after, the iPad was released, which could run iPhone apps too. Suddenly, that restriction made sense. Apple wanted the designs to make sense for people using iPads as well. Is it a bit of a control-freak thing to do? Sure. But there's no reason to do stuff like that unless it's to improve the end-user experience.

Here's another example: Using undocumented APIs. A lot of people point to this as evidence that Apple are hobbling apps, artificially limiting their functionality. But any developer will tell you that people using non-public APIs is a nightmare for forwards compatibility. As soon as there's applications in the wild using an API, you'll have to make the choice between supporting it, unchanged, for eternity, or breaking things for users. Ask Microsoft- they've still got a tonne of backwards compatibility code in Windows because sometime in the early 90s, applications rooted out private APIs and depended on them to function.

How about another example: I've had an application rejected for giving a misleading error message. If somebody was trying to log in and their Internet connection wasn't up, it told them their username and password was wrong instead of telling them to check their connection. A dumb bug, but one that could confuse end users.

It doesn't really make sense for Apple to invest in this approval process, and piss off developers, and slow the whole thing down to a crawl if this is just a pretext for having a walled garden. Apple aren't shy about being control freaks. If it was just about being a walled garden, they'd say so, they are shameless about it.

Sometimes the simplest explanation is the right one - Apple have an approval process that rejects applications on quality and UX grounds because they want to ensure the quality of applications on the App Store. They might also have other motivations as well, but there's no reason to believe that that one is anything other than genuine.

Comment Re:I call bullshit on "unaware" claims (Score 4, Informative) 206

Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet.

Read the paper - they watched the interaction in a debugger to find the right messages to send to the right private classes in order to bypass this.

This only worked with iOS 5 - last year Apple moved sheets like these into external processes and used a proxy view controller to show them in applications instead of embedding the functionality directly, so attacks like this aren't possible any more where this technique has been used.

I agree that this is somewhat sensationalised, but they were able to do this without the normal user approval in the 4% or so of people still running a two year old version of iOS.

Comment Re:Q&A (Score 5, Insightful) 206

I'm an iOS developer, and the approval process can be a real problem for me sometimes, but I still think the App Store is far better with it than without it.

I've seen a lot of clients ask for dumb stuff. Using UI elements in confusing ways. Doing user-abusive stuff. Being generally annoying and self-serving rather than being designed with the user's best interests as a goal.

The great thing about the approval process is that I can tell those clients "Apple won't allow it" and it instantly shuts them up. The alternative would be hours of trying to convince them not to do something horrible, which leaves everybody unhappy no matter what decision is made. And this is the best case scenario, when you've got a developer willing to go to bat for the users. There's plenty of developers out there who will blindly do whatever the client asks, no matter how shitty it makes the UX.

It's not just bad decisions. It's QA as well. Do you have any idea how keen people are to just push stuff live and then fix it after? I don't know about you, but I don't want a dozen updates every morning as developers meddle with their apps trying to get things right. The approval process gives developers the stick necessary to perform proper QA. We don't dare push anything live if there's the possibility of a crasher, because Apple will reject it and we have to wait another week to get reviewed again.

If the approval process wasn't there, then the quality of the apps on the App Store would plummet. You think it's bad with Android, but Android doesn't attract the worst kinds of ambulance chasers. The App Store would be 75% Geocities level quality in no time at all.

What I do disagree with is making the App Store the only way to get applications onto the device. There's really no legitimate reason for not allowing side-loading for people willing to go into settings and agree to a disclaimer.

Comment Re:iOS apps -- can they self-modify? (Score 1) 206

For the most part, yes, but not in the way you think. Objective-C is a very dynamic language. It's not really about sandboxing - apps can't modify their own code. What they can do is include components that do fairly generic, innocuous things, then take external input and construct messages to those existing components on the fly based on that input.

Slashdot Top Deals

It has just been discovered that research causes cancer in rats.