You can even show them a Word doc doing change control, they solved that for docs too. Computers are absolutely outstanding at this task, they were practically designed to do it. If you're not familiar with it, your boss probably is.
The difference with development is, it's ABSOLUTELY POSITIVELY CRITICAL. We manage millions of lines of code, and there's no human to figure out what we meant or fill in blanks from careless edits. It allows us to track down the root cause of bugs, and avoid making the same mistakes in the future. It allows us to recover from mistakes, and means we don't lose months of work from accidental deletions, or worse, overwrites. It allows patches, branches, or bugfix upgrades where we can take 10 minutes to fix a bug instead of having to rush finish the massive new feature we're working on and then force the user to install that. It's part of our most basic toolset, along with a text editor and compiler/interpreter. Show them a photo of a professional mechanic's shop, with tools clean and neatly arranged on pegs and in toolboxes. Then show them a garage with tools in piles everywhere, covered in grease, half of them broken. That's one tenth of the difference.
If my workplace didn't supply version control, I'd use my own. If I couldn't do so much as install a local git/Subversion repo... forget it. I'd start looking for another job, but to tell the truth that's an interview question for me, so I wouldn't be working there in the first place. Seriously. I hate doctor-programmer comparisons, but I can't think of another sufficiently visceral metaphor, so here goes: A programmer who doesn't like source control is a surgeon who eschews scalpels and prefers to dig in with his bare hands.
That letter from Claptrap was outstanding marketing material. When you make a not-great port, and you want to sell the sequel, man that's how you do it. If I hadn't gotten this game free with my sweet new video card, I'd absolutely buy it based on:
a.) The original was pretty fun from a gameplay perspective, and the good characters were just great. That one-legged guy? Loved that guy, 'till they hung him from the ceiling fan.
b.) They actually address the issues. They seem to understand what was wrong. This is the most important part. Would have liked seeing something about having an ending though.
c.) The activation code was for Steam. Fuck yeah I love Steam, so bullshit free, I just play games.
I'm sold. Er, I was already sold, I guess, since there was no opt-out for getting the free thing. But I'll look real hard at future games these guys put out, and unless Borderlands 2 turns out bad (I'll still forgive a terrible ending, but you guys could really seal the deal if you didn't go, "hey, here's everthing you worked for, now just before you touch it HAHAHA GAME OVER NO DENOUEMENT FOR YOU FUCKER."
I was assuming that the key generator is separate from the general CAN bus, if that's not the case, the only thing I could think is to do the same as Ford, and build in a 4-hour (instead of Ford's 10 minutes) delay from key generation request to delivery. But, if you don't like that solution either, I still have a couple suggestions:
1.) Don't drive a conspicuously expensive car that needs to go to extreme anti-theft measures.
2.) If you anticipate your girlfriend repeatedly losing your car keys, make many duplicates in advance at the same time.
I guess there's nothing you can do about losing the keys even though that's the obvious place to start, but man that's got to be frustrating. In 15 years of driving, I've never lost a single car key (or wallet, or cell phone, although I leave $8 sunglasses everywhere), and I'm not a particularly careful person. I've never even known anyone to lose a car key. I can't even imagine the level of air-headedness required to lose multiples.
Or security by economy of effort. As it is, it takes 2 minutes to access the port to reprogram keys. If that port and its wires were buried in the engine so that you had to put the car on a lift and take it half apart to access, they'd move on to easier targets.
Being able to create duplicate keys from the car itself is great. The lock doesn't have to be unbreakable, just more trouble to break than it's worth.
No, this is like saying you're reasonably sure you're looking at your list of customers because the list of potential customers is something like 100 million and the list of your customers is 1 million, and the list in question matches your current list to within 2%, and even an app that you linked directly or directly linked your app having such a similar list of 1% of iPhone owners is such a huge stretch that it's not even really an entertainable possibility.
No car analogy necessary, it's pretty easy to understand, and the analogy is inaccurate anyway.
Numerically, in comparison to the number 1, yes, 2% of 1,000,000 is a lot. However, when the list is a current list of known UDIDs, which you get from users who have installed your apps, and you're comparing a list that was leaked at some time in the past that was at least a week ago with your current list, a 2% change in the sets isn't that much.
The question isn't whether what you have now is enough to do what you're already doing. Obviously, it's sufficient even if it could be better. The question is, what aren't you doing that you would be doing if you had a 50x50 connection? What aren't you doing that you would be doing if everyone had a 50x50 connection?
I'm not sure you'll have a lot of luck getting people to take advice from somebody who would stick a serrated knife in their own rectum before doing basically anything other than sticking two serrated knives in their own rectum.
Actually studies have shown that people react better in emergency situations with a joystick, in that they're more likely to steer and brake at the same time. I can't say whether it makes you able to take a corner more optimally, but in passenger cars, where safety is the primary concern as opposed to a race car, a steering wheel and pedals isn't as good as it gets.
There is such a thing as a book factory, it's called a printing press, and you can inherit it. The metaphor doesn't really work because its space is already occupied.
And while you can inherit the design for a hammer in patent form, your monopoly is protected for considerably less time (than the effectively unlimited duration we've seen so far for copyright).
I simply don't see how the arts protected by copyright are so incredibly important to society or require such a large up-front investment that we need to protect the monopoly for almost a century, compared to patents.
Or maybe the trick is to mod-bomb anyone I disagree with with a bunch of Overrated mods like some generous soul did in this thread. Particularly telling is that they modded down the posts with actual facts, citations, and logical arguments in them instead of the posts where this degenerated into nothing more than an immature slapfight. Why bother to support assertions when you can just silence your opponents with a dropdown?
Ohohoho, you got me good! And thank you for your kind wishes. I've had a wonderful life so far and hope it stays that way too. Although perhaps I could find some improvement if I tried to win arguments with appeals to authority and insults instead of facts and reason. I'd have more time on my hands at least.
Ah, completely unsubstantiated claims of uber-leetness in response to me refuting your arguments and irrelevant misdirection attempts. Good work. Way to address the fact that my point the entire time has been that restricting allowed characters based on the control characters of its eventual possible destination is a weak and error-prone security practice.
I've already conceded that it is no longer supposed to be possible.
The point is that it's not a strong security technique. If you look at the first release of the spec you linked, you'll find that there is no mention of the Referer header, and according to the spec, the opposite behavior is what was specified, and that specification was in fact followed. Do some googling, you'll find many references to this working. And XMLHttpRequest came out in 1999, so it's spent most of its life in its insecure incarnation.
Even if relying on the server to not accidentally send malicious content based on a header that the client sent was a good idea, redefining a header from insecure to secure is an inherently bad idea.
You're also trying to argue both sides here, by saying that browsers need to deal in the real world, but at the same time they should make assumptions that could only be valid if every browser instantly followed specifications as they were released. In the real world, the header was redefined, and the redefinition caused years later as developers "missed spots" when securing it. In the real world, it's easier to create an entirely new header that is supposed to be secure from the beginning--if the header is there, you are safe to assume it's secure. If it's not, you don't have that security and can make an informed decision as to whether or not to continue. In redefining the header, they took that choice away and created a situation where you had to rely on browser sniffing to determine if you're dealing with the secure or insecure version of the header (although, in the real world, nobody bothered with that because it was so spectacularly difficult to get right). It's terrible security practice all around, and this should be obvious to anyone who's actually done development.
I invite anyone to provide an objective reason or reference to the same why this would not work in the "real world".
It didn't work in the real world, as evidenced by the years spent where referer spoofing was a common attack. Just because we slogged through and came out on the other side eventually doesn't mean that we couldn't have done better by taking the obviously better tack of creating a new header.
I personally think that we could do one better by not relying on any sort of referrer mechanism, but at the very least, saying the way it was done is the best way in light of the history of the issue is silly.
First off, the article never states your assertion. In fact, "API" never appears once in it. He does, however, reference HTML, Perl, Cookies, URIs... you get the idea. I think it's possible that you're the one who doesn't understand what was written.
For an actually relevant argument though, the approach's failings are only more apparent at that level. If you're talking directly to the SQL server, why in God's name would you do anything other than ask the SQL library to handle your validation? You don't have to guess what characters to allow or carefully consider, you can just go look it up since you're talking directly to the server/filesystem/whatever. And restrictions in APIs are much more serious than restrictions in a UI. You can generally rip out the UI and put a new one on, but you're often stuck bridging two APIs together. If they disagree on their arbitrary restrictions, well, now you've got a "fun" project on your hands.
And if you can't write secure Javascript (it involves not giving JS the power to cause problems), I wouldn't go advertising that. The simple act of being capable of programming Javascript disqualifies one from being able to write secure code? Please. What you uttered is very similar to something I heard a guy say once: "I'm not a web developer, I'm a backend guy" as a defense against something stupid he did in the web app he was developing. No, you are a web developer, you're just a bad one. The idea that there's certain programming tasks that are "below" you is ridiculous. If you can't do the easy stuff, why should anyone trust you to do the hard stuff?
It's funny how the more strident you get in your defense of these antiquated techniques, the more your misguided elitism shows.
Default accept or default deny is splitting hairs when you're doing it wrong in the first place. It specifically says:
However, most programs can be quite strict and only accept a very limited subset of e-mails to work well. In most cases, it's okay to reject technically valid addresses like "John Doe <john.doe@somewhere.com>" as long as the program can accept normal Internet addresses in the "name@domain" format (like "john.doe@somewhere.com").
And this is under the heading "Secure programmer". If your security depends on rejecting valid e-mail addresses, it's terrible. This isn't hard, I do it all the time. What programming environment doesn't have an e-mail address parser already built-in? As for "It suggests no such thing", it suggests exactly what I said it does:
The biggest problem is figuring out exactly what should be legal in the string. In general, you should be as restrictive as possible. There are a large number of characters that can cause special problems; where possible, you don't want to allow characters that have a special meaning to the program internals or the eventual output. That turns out to be really difficult, because so many characters can cause problems in some cases.
Metacharacters: Metacharacters are characters that have special meanings to programs or libraries you depend on, such as the command shell or SQL.
The author is correct that it's really difficult, but it's also really inadvisable, so no big deal. Any halfway decent SQL library has a way to escape SQL. Why would you re-invent the wheel, except square? An apostrophe is harmless in SQL except in certain contexts, which the SQL library handles when you put it through a parametrized query. For added fun, different databases have different rules on what's escaped where. Double single-quotes, backslash single-quote, you have to change whenever you change your backend. So, you put that logic in your Javascript, and you've now coupled your database layer to your UI. It's an insane, confused approach that has been recommended since 1995 and has proven to be highly ineffective, requires doing things perfectly over and over and over again, destroys program structure, needlessly restricts capabilities, and flat-out doesn't make sense. You're protecting the wrong end, out of some misguided overstretched metaphor where certain input is some abstract "poison", and you don't want to let it into your "system".
I don't. I'm not sure it's even common enough to be considered a pattern, let alone have good libraries, those names are just things I came up with in the moment.
What it essentially boils down to though is you create classes and conversions between those classes that always maintain the correct escaping. If you find yourself writing the same escaping method more than once, refactor. There should be One Version of the Truth, that is a pattern. You then write output routines that refuse to render unrecognized classes, and only ever output using those routines.
To be honest though, I'd step very carefully when leaning hard on PHP's type system as this technique does. It's got so much missing functionality you'll find yourself painted into unexpected corners, and yet is so permissive that it makes it very hard to make it hard to do things wrong. It really shines in C++ or to a slightly lesser extent C#, but obviously you can't just change languages at a whim, and not many people use C++ for web development.
There are legitimate reasons to want to do this, and people are much more likely to be helpful when you're not asking how to exploit. With that in mind, the search set referer xmlhttprequest gives decent results. If you look through them, you'll see that it used to work in basically every browser by simply setting the header, but there are now various levels of protection depending on the browser, the calling code's domain, and where the request is going.
All in all, basing security on a header that was never secure is a dumb idea. Instead of redefining an old header, make a new one. This is security we're talking about, not opening a Word 97 document on Word 2008. If it's not secure, it should break, it shouldn't make a best effort.
Dammit, I was going to whip up a quick example of this, and a google showed me that browsers have added protection to the XMLHttpRequest. I was basing my claim on years-old information. My bad.
I mean, I still think it's not a good idea, and that same google shows that there are many ways around it, and other headers don't share the same protection so trusting them is a bad habit to get into, but it looks like it would take more than the two minutes I was willing to spend. Google around. It may not be trivial anymore, but it's still very possible.
Slashdot Mirror
You can even show them a Word doc doing change control, they solved that for docs too. Computers are absolutely outstanding at this task, they were practically designed to do it. If you're not familiar with it, your boss probably is.
The difference with development is, it's ABSOLUTELY POSITIVELY CRITICAL. We manage millions of lines of code, and there's no human to figure out what we meant or fill in blanks from careless edits. It allows us to track down the root cause of bugs, and avoid making the same mistakes in the future. It allows us to recover from mistakes, and means we don't lose months of work from accidental deletions, or worse, overwrites. It allows patches, branches, or bugfix upgrades where we can take 10 minutes to fix a bug instead of having to rush finish the massive new feature we're working on and then force the user to install that. It's part of our most basic toolset, along with a text editor and compiler/interpreter. Show them a photo of a professional mechanic's shop, with tools clean and neatly arranged on pegs and in toolboxes. Then show them a garage with tools in piles everywhere, covered in grease, half of them broken. That's one tenth of the difference.
If my workplace didn't supply version control, I'd use my own. If I couldn't do so much as install a local git/Subversion repo... forget it. I'd start looking for another job, but to tell the truth that's an interview question for me, so I wouldn't be working there in the first place. Seriously. I hate doctor-programmer comparisons, but I can't think of another sufficiently visceral metaphor, so here goes: A programmer who doesn't like source control is a surgeon who eschews scalpels and prefers to dig in with his bare hands.
That letter from Claptrap was outstanding marketing material. When you make a not-great port, and you want to sell the sequel, man that's how you do it. If I hadn't gotten this game free with my sweet new video card, I'd absolutely buy it based on:
a.) The original was pretty fun from a gameplay perspective, and the good characters were just great. That one-legged guy? Loved that guy, 'till they hung him from the ceiling fan.
b.) They actually address the issues. They seem to understand what was wrong. This is the most important part. Would have liked seeing something about having an ending though.
c.) The activation code was for Steam. Fuck yeah I love Steam, so bullshit free, I just play games.
I'm sold. Er, I was already sold, I guess, since there was no opt-out for getting the free thing. But I'll look real hard at future games these guys put out, and unless Borderlands 2 turns out bad (I'll still forgive a terrible ending, but you guys could really seal the deal if you didn't go, "hey, here's everthing you worked for, now just before you touch it HAHAHA GAME OVER NO DENOUEMENT FOR YOU FUCKER."
If you only have to buy one per lifetime, what's $30-50?
that's it.
Other than the 3GS that is.
It's more polite to keep the finger when cutting someone up?
I was assuming that the key generator is separate from the general CAN bus, if that's not the case, the only thing I could think is to do the same as Ford, and build in a 4-hour (instead of Ford's 10 minutes) delay from key generation request to delivery. But, if you don't like that solution either, I still have a couple suggestions:
1.) Don't drive a conspicuously expensive car that needs to go to extreme anti-theft measures.
2.) If you anticipate your girlfriend repeatedly losing your car keys, make many duplicates in advance at the same time.
I guess there's nothing you can do about losing the keys even though that's the obvious place to start, but man that's got to be frustrating. In 15 years of driving, I've never lost a single car key (or wallet, or cell phone, although I leave $8 sunglasses everywhere), and I'm not a particularly careful person. I've never even known anyone to lose a car key. I can't even imagine the level of air-headedness required to lose multiples.
Or security by economy of effort. As it is, it takes 2 minutes to access the port to reprogram keys. If that port and its wires were buried in the engine so that you had to put the car on a lift and take it half apart to access, they'd move on to easier targets.
Being able to create duplicate keys from the car itself is great. The lock doesn't have to be unbreakable, just more trouble to break than it's worth.
I miss driving the 20-year-old BMW I bought for $2,000. Wish somebody would have told me about the trust fund, I sure could have used it!
No, this is like saying you're reasonably sure you're looking at your list of customers because the list of potential customers is something like 100 million and the list of your customers is 1 million, and the list in question matches your current list to within 2%, and even an app that you linked directly or directly linked your app having such a similar list of 1% of iPhone owners is such a huge stretch that it's not even really an entertainable possibility.
No car analogy necessary, it's pretty easy to understand, and the analogy is inaccurate anyway.
Numerically, in comparison to the number 1, yes, 2% of 1,000,000 is a lot. However, when the list is a current list of known UDIDs, which you get from users who have installed your apps, and you're comparing a list that was leaked at some time in the past that was at least a week ago with your current list, a 2% change in the sets isn't that much.
The question isn't whether what you have now is enough to do what you're already doing. Obviously, it's sufficient even if it could be better. The question is, what aren't you doing that you would be doing if you had a 50x50 connection? What aren't you doing that you would be doing if everyone had a 50x50 connection?
I'm not sure you'll have a lot of luck getting people to take advice from somebody who would stick a serrated knife in their own rectum before doing basically anything other than sticking two serrated knives in their own rectum.
Actually studies have shown that people react better in emergency situations with a joystick, in that they're more likely to steer and brake at the same time. I can't say whether it makes you able to take a corner more optimally, but in passenger cars, where safety is the primary concern as opposed to a race car, a steering wheel and pedals isn't as good as it gets.
There is such a thing as a book factory, it's called a printing press, and you can inherit it. The metaphor doesn't really work because its space is already occupied.
And while you can inherit the design for a hammer in patent form, your monopoly is protected for considerably less time (than the effectively unlimited duration we've seen so far for copyright).
I simply don't see how the arts protected by copyright are so incredibly important to society or require such a large up-front investment that we need to protect the monopoly for almost a century, compared to patents.
Yeah, it's probably that her strong immune system negates the inhibiting effects that catching colds from sleeping around would normally cause.
Or maybe the trick is to mod-bomb anyone I disagree with with a bunch of Overrated mods like some generous soul did in this thread. Particularly telling is that they modded down the posts with actual facts, citations, and logical arguments in them instead of the posts where this degenerated into nothing more than an immature slapfight. Why bother to support assertions when you can just silence your opponents with a dropdown?
Ohohoho, you got me good! And thank you for your kind wishes. I've had a wonderful life so far and hope it stays that way too. Although perhaps I could find some improvement if I tried to win arguments with appeals to authority and insults instead of facts and reason. I'd have more time on my hands at least.
And you think you were saying anything different? Please.
Ah, completely unsubstantiated claims of uber-leetness in response to me refuting your arguments and irrelevant misdirection attempts. Good work. Way to address the fact that my point the entire time has been that restricting allowed characters based on the control characters of its eventual possible destination is a weak and error-prone security practice.
I've already conceded that it is no longer supposed to be possible.
The point is that it's not a strong security technique. If you look at the first release of the spec you linked, you'll find that there is no mention of the Referer header, and according to the spec, the opposite behavior is what was specified, and that specification was in fact followed. Do some googling, you'll find many references to this working. And XMLHttpRequest came out in 1999, so it's spent most of its life in its insecure incarnation.
Even if relying on the server to not accidentally send malicious content based on a header that the client sent was a good idea, redefining a header from insecure to secure is an inherently bad idea.
You're also trying to argue both sides here, by saying that browsers need to deal in the real world, but at the same time they should make assumptions that could only be valid if every browser instantly followed specifications as they were released. In the real world, the header was redefined, and the redefinition caused years later as developers "missed spots" when securing it. In the real world, it's easier to create an entirely new header that is supposed to be secure from the beginning--if the header is there, you are safe to assume it's secure. If it's not, you don't have that security and can make an informed decision as to whether or not to continue. In redefining the header, they took that choice away and created a situation where you had to rely on browser sniffing to determine if you're dealing with the secure or insecure version of the header (although, in the real world, nobody bothered with that because it was so spectacularly difficult to get right). It's terrible security practice all around, and this should be obvious to anyone who's actually done development.
I invite anyone to provide an objective reason or reference to the same why this would not work in the "real world".
It didn't work in the real world, as evidenced by the years spent where referer spoofing was a common attack. Just because we slogged through and came out on the other side eventually doesn't mean that we couldn't have done better by taking the obviously better tack of creating a new header.
I personally think that we could do one better by not relying on any sort of referrer mechanism, but at the very least, saying the way it was done is the best way in light of the history of the issue is silly.
First off, the article never states your assertion. In fact, "API" never appears once in it. He does, however, reference HTML, Perl, Cookies, URIs... you get the idea. I think it's possible that you're the one who doesn't understand what was written.
For an actually relevant argument though, the approach's failings are only more apparent at that level. If you're talking directly to the SQL server, why in God's name would you do anything other than ask the SQL library to handle your validation? You don't have to guess what characters to allow or carefully consider, you can just go look it up since you're talking directly to the server/filesystem/whatever. And restrictions in APIs are much more serious than restrictions in a UI. You can generally rip out the UI and put a new one on, but you're often stuck bridging two APIs together. If they disagree on their arbitrary restrictions, well, now you've got a "fun" project on your hands.
And if you can't write secure Javascript (it involves not giving JS the power to cause problems), I wouldn't go advertising that. The simple act of being capable of programming Javascript disqualifies one from being able to write secure code? Please. What you uttered is very similar to something I heard a guy say once: "I'm not a web developer, I'm a backend guy" as a defense against something stupid he did in the web app he was developing. No, you are a web developer, you're just a bad one. The idea that there's certain programming tasks that are "below" you is ridiculous. If you can't do the easy stuff, why should anyone trust you to do the hard stuff?
It's funny how the more strident you get in your defense of these antiquated techniques, the more your misguided elitism shows.
Default accept or default deny is splitting hairs when you're doing it wrong in the first place. It specifically says:
However, most programs can be quite strict and only accept a very limited subset of e-mails to work well. In most cases, it's okay to reject technically valid addresses like "John Doe <john.doe@somewhere.com>" as long as the program can accept normal Internet addresses in the "name@domain" format (like "john.doe@somewhere.com").
And this is under the heading "Secure programmer". If your security depends on rejecting valid e-mail addresses, it's terrible. This isn't hard, I do it all the time. What programming environment doesn't have an e-mail address parser already built-in? As for "It suggests no such thing", it suggests exactly what I said it does:
The biggest problem is figuring out exactly what should be legal in the string. In general, you should be as restrictive as possible. There are a large number of characters that can cause special problems; where possible, you don't want to allow characters that have a special meaning to the program internals or the eventual output. That turns out to be really difficult, because so many characters can cause problems in some cases.
The author is correct that it's really difficult, but it's also really inadvisable, so no big deal. Any halfway decent SQL library has a way to escape SQL. Why would you re-invent the wheel, except square? An apostrophe is harmless in SQL except in certain contexts, which the SQL library handles when you put it through a parametrized query. For added fun, different databases have different rules on what's escaped where. Double single-quotes, backslash single-quote, you have to change whenever you change your backend. So, you put that logic in your Javascript, and you've now coupled your database layer to your UI. It's an insane, confused approach that has been recommended since 1995 and has proven to be highly ineffective, requires doing things perfectly over and over and over again, destroys program structure, needlessly restricts capabilities, and flat-out doesn't make sense. You're protecting the wrong end, out of some misguided overstretched metaphor where certain input is some abstract "poison", and you don't want to let it into your "system".
I don't. I'm not sure it's even common enough to be considered a pattern, let alone have good libraries, those names are just things I came up with in the moment.
What it essentially boils down to though is you create classes and conversions between those classes that always maintain the correct escaping. If you find yourself writing the same escaping method more than once, refactor. There should be One Version of the Truth, that is a pattern. You then write output routines that refuse to render unrecognized classes, and only ever output using those routines.
To be honest though, I'd step very carefully when leaning hard on PHP's type system as this technique does. It's got so much missing functionality you'll find yourself painted into unexpected corners, and yet is so permissive that it makes it very hard to make it hard to do things wrong. It really shines in C++ or to a slightly lesser extent C#, but obviously you can't just change languages at a whim, and not many people use C++ for web development.
There are legitimate reasons to want to do this, and people are much more likely to be helpful when you're not asking how to exploit. With that in mind, the search set referer xmlhttprequest gives decent results. If you look through them, you'll see that it used to work in basically every browser by simply setting the header, but there are now various levels of protection depending on the browser, the calling code's domain, and where the request is going.
All in all, basing security on a header that was never secure is a dumb idea. Instead of redefining an old header, make a new one. This is security we're talking about, not opening a Word 97 document on Word 2008. If it's not secure, it should break, it shouldn't make a best effort.
Dammit, I was going to whip up a quick example of this, and a google showed me that browsers have added protection to the XMLHttpRequest. I was basing my claim on years-old information. My bad.
I mean, I still think it's not a good idea, and that same google shows that there are many ways around it, and other headers don't share the same protection so trusting them is a bad habit to get into, but it looks like it would take more than the two minutes I was willing to spend. Google around. It may not be trivial anymore, but it's still very possible.