Hacker Newsnew | past | comments | ask | show | jobs | submit | more vertex-four's commentslogin

When you’re paid minimum wage in the US, and you’re not permitted to perform a full-time job, you probably have to hold down multiple jobs; you probably also don’t get things like healthcare from any of them.

Zero hours contracts in theory mean you can refuse work (at least that’s how it works in the U.K.), but obviously you’re going to be fired for doing so, so you’re essentially constantly on call for both/all your jobs.


if you have multiple jobs, then you clearly have time to find another job.


If you have multiple jobs and must take every hour they ask of you, you clearly do not have time to find another job; you are very likely working more than a full-time job without adequate protections.

Look, here’s how it goes:

1) you have no job

2) you take the first job that comes your way, even if it doesn’t actually pay enough to survive - a little money is better than no money

3) you take the second job that comes your way so that you can survive

4) you have no time to actually do anything towards getting a better job

Understand?

This is why jobs that pay less than what is needed to survive are bad for individuals and bad for society; people have to take them. Nobody is going to help you survive otherwise.


if you have multiple jobs, you already have another job, so it was clearly possible.


The difference here is that the second job you have is likely going to be just as terrible as your first, where the improvement comes not from having a better job but simply having access to more hours and therefore more hourly pay.

Searching for a job that is _mechanically better_ (think office job versus min-wage retail) is significantly more challenging than finding a min-wage job. For example, most salaried or otherwise higher paying jobs require multiple rounds of interviews while many min-wage jobs will hire you on the spot to fill a staff position.


No. It means it’s possible to find a second job when you only have one. It doesn’t mean that once you’ve found a second job you still have time to search for an improved job.


You’re intentionally not getting it. I don’t know how to make this clearer than what I wrote, especially as you haven’t actually responded to what i wrote.


I'd would say that you are intentionally not getting it. I wasn't responding to you, I was clarifying for your benefit. As someone who's worked minimum wage jobs, I know exactly how it is, so I really don't need to be told. I'm also my union rep at work, so this isn't coming from a anti-union stance in the slightest, I absolutely see the value.


So when you were working multiple minimum wage jobs because one didn’t cover your living costs, did you have time to find something better? Could you quit them to find something better? My friends sure don’t and can’t.


Many times, if you're having to take on another job, you don't have the luxury of "time" to find the best one, e.g. pays well, has benefits, etc. You take the first or second job that comes to you and work for as much time as possible at that one as well. Speaking from experience, people don't take on multiple jobs just to work them for an hour or two a day.


no, working an additional job does not give you more hours in a day. rather it consumes time. what do you do at work?


I'm responding to what's written. If you have a job at walmart, they can't both have zero time to find another job because of being beholden to their job at walmart and have another job.


...but they can have zero time to find another job because of being beholden to their job at Walmart, and to the other job?

You're saying they should keep the Walmart job and get rid of the other, and spend the time freed up searching for one that's full time and paid enough to replace both, right? But if you can't support yourself and your dependants on the Walmart job alone, then that's risky.


if they have the other job already, then they clearly had time. I'm not saying they should do anything. I'm saying it doesn't make sense that you can be beholden to a job because of too many hours, and have reduced hours. It's one or the other.


This is covered by search theory in economics. (economists do not use "supply and demand" for jobs, rather they consider things like search time and monopsony power.)


You the taxpayers are the people who would prefer these people stay in prison than release them. You took on the responsibility when you put in place a system to imprison them. You could always campaign for prison abolition if you don’t want the responsibility...


> You the taxpayers are the people who would prefer these people stay in prison than release them.

That's a rather broad blanket statement bordering on collective punishment (which BTW is classified as a war crime by the UN). The status of taxpayer makes you a victim of the state, not necessarily someone with influence over its behavior and certainly not an ardent supporter of all its policies. The vast majority of the taxpayers had nothing to do with the situation and might well be opposed to keeping these people in prison if the facts were explained to them.

Perhaps the matter should be put to a general vote—those actually in favor of keeping the inmates in prison can split the cost of any wrongful-imprisonment suit in the event the state loses.


Luckily I’m not at war with anyone. The vast majority of the population do approve of the prison system though, and shrugging off responsibility for what that means seems perverse.


As far as I can tell, this article refers to the difficulty in compiling wasm into native code to run, not compiling code into wasm.


Nobody comes up with any ideas independently - Uber weren’t the first to think of an app for taxis.


You're either interpreting what I said entirely too literally or maybe I was a bit unclear. If they saw somebody else's implementation of "chapter delivery of ebooks by email" online and then proceeded to roll their own with zero credit to the original creator, that is ethically WRONG. It scares me as a developer myself to see how many people are totally okay with the Mark Pincus approach.


“Knowing your customer” is not equivalent to performing surveillance on your customers. People knew their customer for centuries before we could tell that a random unwitting user spent 1.6 minutes on the page and exactly where they put their mouse cursor while they were on it.


I don't know where you live or what your internet setup is like, but I can't stream 4k at ridiculously high bitrates consistently, and apparently many of Netflix's customers can't either: "The number of rebuffers per hour go down by over 65%; members also experience fewer quality drops while streaming." Additionally, "members who were limited by their network to 720p can now be served 1080p or higher resolution instead."


I must admit that I have not read Greta Thunberg's book, but if it has a solution to capitalism's demand that we make sacrifices to our personal morals or starve in the specific instance of the tooling we need to perform our work, I'd love to hear it. You don't get to say "I am not using computers any more as they contain components made in China" and keep your job as a software developer, and you'd be very unlikely to receive unemployment benefits.

The only way we're getting there is actual organisation and uprising to overthrow the capitalism which requires that we make those sacrifices, and frankly... it's not going to happen any time soon. People broadly agreed to the National Guard being sent in to handle some people who were mostly demanding that the police stop killing them, can you imagine what would happen if those people were actually calling to overthrow the state?


I mean, for most of us on here, it's either use goods made at least partially in China or switch career - you're never going to get a computer with no Chinese-made components, especially not at a price which I can afford. Good luck doing that without years of planning, and managing to continue to feed yourself.

Fact of the matter is that China is in an extremely powerful position over the world due to its position in the manufacturing chain. The world would fall apart overnight if China stopped manufacturing things - parts of it did already when Covid-19 caused lockdowns. There isn't the manufacturing ability elsewhere to scale up to what China provides.


Web browser DNS resolution hasn't gone through libc in a long time.


Really? Because I remember it respecting the libc resolver configuration are least shortly before the change, now it just ignores it.


Most DNS resolution libraries will read the libc resolver configuration (/ets/nsswitch.conf) and attempt to parse it into something they understand, and potentially fall back to it (for example, if you're doing non-DNS resolution like mDNS).

If you'd like to standardise a way to require DNS-over-HTTPS in supporting software, and convince operating system distributors to generally ship it, I'm fairly sure Firefox would be up for using that rather than its current mechanism, similar to how it uses system proxy settings. As it is there is no such standard.


> If you'd like to standardise a way to require DNS-over-HTTPS in supporting software, and convince operating system distributors to generally ship it, I'm fairly sure Firefox would be up for using that rather than its current mechanism, similar to how it uses system proxy settings. As it is there is no such standard.

There already is a standard way for me to tell all the programs which run on my system which DNS servers to use: /etc/resolv.conf. Any program which does not respect the values I set there is disobeying me.


There is no way to say in /etc/resolv.conf that you want to use a DNS-over-HTTPS server.


> There is no way to say in /etc/resolv.conf that you want to use a DNS-over-HTTPS server.

Sure there is:

    nameserver 127.0.0.1
where I choose to run a nameserver which uses DNS-over-HTTPS on 127.0.0.1:53.


And so we get incredibly far away from the very laudable goal of protecting Internet users - the majority of who primarily use a web browser - by default from malicious DNS servers.


Chrome automatically upgrades known DNS providers to DoH.


Still, it is reasonable to export a standard control interface to the user for site filtering and control.


There isn't one today, aside from running your own DNS server, and you can run your own DNS-over-HTTPS server. My understanding is that Firefox still respects /etc/hosts in DNS-over-HTTPS mode, too. I'm unaware of any such tooling that installs a glibc resolver stub.

RFC8890 explicitly refers to "the interests of that child's parents or guardians" when the child is using a web browser, although individual system configuration is not within the remit of the IETF.

RFC 8484 makes no reference to how DNS-over-HTTPS should be configured, and in the face of widespread DNS hijacking, enforcing DNS-over-HTTPS in browsers may have been the correct solution - but that doesn't mean we can't do better by defining a standard (perhaps under the remit of the Free Desktop XDG group), encouraging operating system vendors to ship secure DNS configured by default, and then convincing Firefox et al to use that standard.


Sure, because big tech pretends to care about privacy and freedom of speech but only insofar as it results in them cutting out every layer of control between their servers and the end users they would like to own. So everything will be tunneled over opaque HTTPS proxies and there will be no facility for people to filter anything - even end users. Apple, for instance, pretends to care about user privacy and control but refuses to offer a configurable IP firewall in iOS or end-user control over name resolution for filtering.


>you can run your own DNS-over-HTTPS server.

Yes, but is there a facility to force the browser to use your server or will Google re-write Chomium to "bypass" "rogue" DoH servers which filter content Google doesn't wish them to filter?


In practice, I reckon you might be the only person in the world - or maybe one of a dozen - who has this problem. And in that context that's not snark at all, it's an accurate description of what is most likely the cause of the error.


> an accurate description

except it's a lie. SNI isn't "more secure", it leaks information to a possible MITM.


It's actually a relic of when I was testing to see how broad SNI adoption was -- see https://www.mnot.net/blog/2014/05/09/if_you_can_read_this_yo...


I don't see how not sending the SNI can improve leaking. If the server has only one hostname associated, it's trivial to get it from the IP and then reverse DNS. This issue is discussed in detail in multiple drafts about SNI encryption


It requires a more modern browser to operate securely; it says nothing about whether it is perfectly secure against all threat models, and this particular website is hosted on the same IP as at least one other so requires SNI to operate securely indeed, and will hopefully in future support ESNI as the software implements it.

BTW - if this site did not use SNI, and only served one website at https://www.mnot.net, then connecting to www.mnot.net's IP address at port 443 would be plenty good evidence that you're accessing https://www.mnot.net. The SNI privacy leak only really comes into play when you're accessing something behind a CDN or a shared hosting provider, which put enough sites behind each IP that simply accessing that IP isn't a privacy leak in itself.


Note that the message isn't saying SNI is more secure. It just says the site needs SNI to operate securely.


The website does not support the more secure ECH nor the more secure option of just not using SNI at all. It's the website that doesn't support a fully secure connection and it shouldn't be blaming the user agent for that.


Encrypted Client Hello isn't even at Working Group Last Call yet, let alone actually published, so it won't make sense for most people to offer whatever the current draft state is.

Not using SNI isn't a more secure option. By definition you can't be doing standards compliant TLS 1.3 - which would be the most secure option - since sending SNI for host names is mandatory in TLS 1.3.

Also, in assuming that multiple hosts can instead be distinguished down in/ up in the HTTP layer you actually do make some things less secure. The TLS session binding doesn't apply to the application layer, so when you write Host: www.example.com in HTTP that does not bind your TLS session to the name www.example.com, whereas if you send SNI for www.example.com then the remote server needs to actively decide by policy if it's safe not to bind that. Are you actually going to get exploited this way? Probably not, but neither are bad guys anxious to find out somehow which of the services on Mark's server you wanted.


ESNI is not supported by common software yet. Can you tell me your alternative to SNI in this configuration:

    [nix-shell:~]$ nslookup redbot.org
    Server:  127.0.0.1
    Address: 127.0.0.1#53
    
    Non-authoritative answer:
    Name: redbot.org
    Address: 45.79.113.165
    Name: redbot.org
    Address: 2600:3c01::f03c:92ff:fe89:3e33
    
    
    [nix-shell:~]$ nslookup www.mnot.net
    Server:  127.0.0.1
    Address: 127.0.0.1#53
    
    Non-authoritative answer:
    www.mnot.net canonical name = cloud.mnot.net.
    Name: cloud.mnot.net
    Address: 45.79.113.165
    Name: cloud.mnot.net
    Address: 2600:3c01::f03c:92ff:fe89:3e33


"Can you tell me your alternative to SNI in this configuration?"

ESNI-enabled lighttpd, nginx or apache: https://185.24.233.103

ESNI-enabled CDN: https://www.cloudflare.com/ssl/encrypted-sni/


Without any tunnelling like VPN or TOR, the safest option would be to have several unrelated services share one certificate, when only looking at MITM vulnerability.

This would in theory ensure that any attacker could only assume the client is accessing at least one service on the target machine.

Setting aside the obvious risk that one of the services could claim to be one of the others, this obviously comes with some other technical limitations.

Again, it's not like the site is doing anything wrong, it just shouldn't be blaming the user for something that's obviously just a technical limitation of the technology being used.


> Setting aside the obvious risk that one of the services could claim to be one of the others

Not much additional risk there when both site's TLS connections are already handled by the same process.


SNI doesn't make the TLS handshake process and more or less secure. The ServerHello and Certificate messages sent by the TLS server are still sent unencrypted.


"The ServerHello and Certificate messages sent by the TLS server are still sent unencrypted."

RFC 8446, page 7:

"All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection."


So use ESNI.


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

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

Search: