Hacker News new | past | comments | ask | show | jobs | submit | hleach's comments login

I don't believe it is that rational. It's an ideological assessment, not a risk assessment.

If you agree with the people holding the guns, you feel safer with them. If you agree with the people holding the rock, you feel safer with them. It doesn't matter what they are holding.


I'm not sure what you mean, takeout is typically 10% to 20% cheaper than the same food served to you at the table.


For every sophisticated business person there are four that need basic math and accounting explained to them.

It's all too common to see them base their entire business around a single percentage above total raw ingredient cost.

While I agree predatory is a strong word, you are missing the point. There is an ecosystem of small businesses that are being cannibalized by delivery app companies. These are the places I enjoy eating, places that are unique and amazing but not necessarily the top rungs of the business ladder.

This is happening because these delivery apps that are run by sophisticated business people haven't even worked out their business model yet.

Asking for transparency isn't asking for too much.


Most of the time I order delivery, I'm not trying to support my favorite places or really any places at all. I just want some noodles, and I'm entirely insensitive to where they come from. The restaurant industry has no intrinsic moral right to make money from my order; it's strange to propose that I should go out of my way to spend more money and waste more time just for the sake of some random owner's bottom line.

When I'm trying to support my favorite restaurants, the ones I do care about for their own sake, I of course go pick the food up myself. I think most people do the same.


If you feel the restaurant industry has no intrinsic moral right to make money on your order then you are 100% mistaken. If they don't make money on your order you don't get food, so it is in your own interest that they do make money on your order. A race to the bottom will get you either crappy food or no food at all.

What surprises me is that on a website with lots of top earners people would still begrudge others to make an honest living. And running a restaurant is a lot more work than writing software.


I'm not sure how to resolve this disagreement. It just doesn't seem plausible to me that restaurants competing against each other in a free market would cause them to all go extinct.


I think resolution would benefit from people being honest about their motives and less logical fallacies.

It seems that your motive is much larger than this specific issue at hand and is being guided by a desire to promote an overarching ideology.

Additionally, you chose to focus in on 5 words of the above poster and ignored everything else. This is very much a strawman.

The person you responded to was very much making a slippery slope argument and I agree with you that it will not mean all restaurants will close or go to shit.

I would however like to know how I can get the information I need to make an informed personal choice.

I would also like to state my desire to allow other people the information they need to make an informed choice. What they do with that information, I really don't care. They can make a financial decision, a moral decision, an ethical decision, base it on a whim, base it on a value assessment, feed the numbers into the seed of a random number generator, I really don't think that is my business or yours.


I'm not sure how you are mistaking my want for transparency on where my money is going with a moral decision.

Is every purchase a moral decision to you perhaps?

It seems you are very much pitching libertarianism here. Perhaps I am not familiar with this part of the dogma.


They are nearly equivalent in terms of functional security.

Function isn't everything though. One example shows an awareness of the security issue and good habit being used despite the low impact. I'd argue that there is a security benefit to using one over the other.

Additionally, it's not as simple as saying "if you can change memory, then you can change memory". Memory exploits are quite often chains of small issues these days and not the simple buffer overflow of old.

For example, being able to overwrite one byte somewhere could lead to the ability to change only part of a variable address. That could be used to redirect a write to the constant string in memory.

Sure it's contrived, but scenarios like this do happen.


> One example shows [...]

Yes,

  printf("Hello, World!\n");
shows an awareness of the security issue and good habit being used.

  printf("%s\n", "Hello, World!");
shows that you think "%s\n\0Hello, World!" (or however the compiler decides to lay out those strings) can't be overwritten with "%p%nHello, World!" (or something to that effect), but "Hello, World!\n" somehow can.


You know that reinforcing habit is not about this trivial example. You are arguing in bad faith.

We've spent the last 20 years cleaning up after the shoddy work of this exact attitude.


We've spent the last 20 years cleaning up after the shoddy work of people (like you) who think avoiding the deficiencies of a thin wrapper over assembly is just a matter of good habits, rather than actually understanding what the hell they're doing.

And breaking up constants into misordered, mishmashed fragments isn't even a good habit in the first place.

Edit: Come to think of it, given that the original complaint was:

> > printf("Hello, World!\n");

> [...] All this requires is a modification to one string in memory and you have an injection vulnerability.

There's also the fact that it's you who is arguing in bad faith, since a: habit wasn't part of it to begin with, and b: you haven't given any example of a case where a habit of writing `printf("%s\n","<some text>");` rather than `printf("<some text>\n");` is useful for anything whatsoever, security or otherwise.


This looks like it goes way beyond ASLR.

There are a series of different protections they are doing. It's not clear if they intend them to be uniquely switchable or if they were just separating them to indicate which attack techniques require which protections.

For example it appears to combat ROP they are additionally encrypting the code segment of the program and decrypting on an as needed basis. I am absolutely sure this would make debugging more difficult. It wouldn't be used on a debug build though so I guess the question is how often would you find yourself debugging a production executable.

I admit I didn't read it in depth and may have missed something but I wonder if they are doing something similar for dynamic libraries or if it relies on the code being available at compile time. If not then I'm sure someone clever will still get around it with ROP.


The debugger doesn't really rely on the code segment being readable generally.


You are conflating the act of debugging with the operation of a "debugger".

Sure you can start at 0 and step forward one instruction at a time, but how often do you do that without at least looking at the code?

Not being able to look ahead or behind but only within what is actively on the stack is certainly a limiting factor in debugging.

It is of course a problem that has been solved before. Someone would develop an unpacker/decrypter for it at some point and make this trivial, but that would still be an added level of complexity.


You have access to the binary itself, you don't need to read it out of the debuggee process.


I agree. I'm not sure I understand your point though. This isn't contrary to anything I said. I mention unpacking which would be a pre-debugger process.

I believe you are just being pedantic about my use of the word "debugging" to include things like unpacking, static analysis, and a variety of tools and processes used.


The binaries aren't preencrypted here, the dynamic nature is the whole point. There's nothing to unpack since you just reference the binary, and no added work for the debugger.

So when you say

> For example it appears to combat ROP they are additionally encrypting the code segment of the program and decrypting on an as needed basis. I am absolutely sure this would make debugging more difficult.

It's just not true.


So yes, you are correct it's being encrypted dynamically at the hardware level.

You just debug in a system without these protections turned on then.


No, I'm saying you don't have to turn off these protections.

Like, can you give an example of a debugging task you have carried out that requires reading the code segment of the running process?


Required? No, but I didn't say impossible. I said "more difficult".

Made easier by? Most everything ever loaded in a debugger.


Just for an example. How about debugging a non trivial issue between a program and a dynamically loaded library.

You can't just scan the IAT/PLT. You are going to have to find load points or manually step through, and maybe calculate function offsets in the library. Not impossible at all.

It is however something you could have just quickly glanced at and found otherwise.


The thing is, it's not really genre bashing.

These "genres" mostly fit very comfortably into their parent category. Even to the point that if you treat it as a strict history of the music, the majority of the subgenres are unnecessary.

It's poorly presented in this regard. It doesn't do a good job of delineating the music and the cultural history.

What is being taken as genre bashing is really tribalism and the subcultural awareness of the author. In contrast to it's failings as a strict musical history, it presents extremely well the cultural history around the music.


I am kind of shocked at the conversation above simply because of how evidently right you are.

Does she have an agenda? Yes clearly. She isn't hiding it. She has a long history of laying it right out in the open.

Does Amazon have an agenda too? Yes and they are ham-handedly trying to pretend they don't.


A salt can't do it's job when it's reused.

There are WPA rainbow tables for common ssid's available online.

If your ssid is "Linksys" it takes only moments to look up a weak password.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: