For pub/sub yes that's correct. For full info though: Redis later added streams (in 5.x) for the don't-wan't-to-miss case: https://redis.io/topics/streams-intro
Clarification there: I have a US-8 behind each TV, taking 802.11af loads to power. For the TV with an AP or something else PoE behind it, those switches can take in 802.11at and output 802.11af on port 8. The TVs themselves aren’t PoE...I’m crazy, just not that crazy :)
I just wanted to chime in from Stack Overflow here and let people know: we are aware of the issue. And we're NOT okay with it. We're trying to sort out how to kill the audio behavior now. It's not very straightforward to find where it's coming from, but we are working on it. We've also reached out to Google for their assistance in tracking it down. If anyone can offer advice, we'll more than happily take it.
- Nick Craver, Architecture Lead at Stack Overflow
It's ridiculous. It's a text-based ad. At worst, it's a clickable image. At what point did it become okay in your minds to let advertisers run arbitrary code?
I've left ads turned on specifically on StackOverflow because 1) I want to support StackOverflow, and 2) I trust them not to run malicious ads.
I don't even care that they're running ads network-wide. But if they're going to be running these kinds of ads anywhere on the site, they're going right on the ad block list along with everyone else.
It’s completely insane. Can you imagine a TV station receiving ads on tapes and playing them to their audience without looking at them first? Can you imagine TV stations occasionally showing ads containing porn, urging people to kill, showing extreme violence during cartoons, or containing specially crafted audio that blows out your speakers, and the TV station just shrugs and says they try their best to stop these things but they can’t stop everything?
Imagine a TV ad that tries to make your phone call a 1-900 number so they can rip you off, and the station says they don’t know where it came from but they’re trying real hard to put a stop to it. And somehow watching the ads themselves before broadcasting them never crosses their mind.
It’s worse than that. Imagine a TV ad which sends malicious code that gets executed to your television, which profiles the hardware in your TV and sends information about your viewing habits (tied to a unique ID) back to the advertiser.
In any other context we would call this a security vulnerability. I think that label also applies here.
I bought a new wifi router and never told the Vizio the new credentials. If it manages to somehow figure out how to log onto the new router, and transmit the data about how I don't own cable service and mostly use it to play retro games? I'm going to be kindof impressed really; at that point, Vizio can have the data.
In the post I linked to, the TV in a similar situation was happily connecting to someone else's (open) WiFi network nearby. You can't really block those…
The state of web ads is closer to the public pinboard only instead of having ads for grandmas couch its Mr CEO trying every trick to drain your money and track you.
The only reason it’s not the same situation is because they’re willing to throw their users under the bus for a little extra cash. If they wanted to exert more control, they absolutely could. Ads would cost more and we’d see fewer distinct ads as a result.
Digital ads could work where every single one is vetted by people before it’s served to any users. There is no reason it can’t work this way, other than it being a lot cheaper to skip that step.
All creatives (and the root templates of dynamically construted ones) are actually audited on the advertiser-facing platforms before they ever get to the publisher.
Unfortunately running javascript means these ads can do anything at any time and change into malware. Other than adding some technical guardrails, the best practice would be to ban bad actors (of which many are known and usually the same shady people) but many large adtech companies look the other way because it makes money and they have no consequences.
Malware and adfraud is primarily a business problem, not a technical one.
It's not that simple. There are many layers in the supply chain that currently requires JS. Publishers can't disable the JS and they can't demand JS-free creatives either.
Of course it’s that simple. Don’t let ads run JS. Done.
You’re saying that doing this would drastically decrease ad revenue. Which is what I’m saying too: it’s about money, not necessity.
Would a site like SO be unable to survive without ads that run arbitrary JS? I don’t know. Even if the answer is that they must do this to survive, it’s still insane that content companies let randos inject arbitrary code into their pages. If this is so entrenched in the industry that there’s no way around it, that just means the industry is insane.
Money is a necessity, that's how SO exists, and it wouldn't sustain its current size if it required JS-free network campaigns or tried to sell all ad space directly.
Simple doesn't mean it's easy or realistic. Yes, adtech has major problems but they're being slowly worked on and won't change overnight. This applies to any other industry where you think can just walk in and solve everything if everyone just did X. Reality doesn't work that way.
We know that advertising can work and make money without arbitrary JS. When there’s a clear existence proof, is it really wrong to say that a problem could be solved by not doing the problematic behavior?
Of course reality doesn’t work that way. Ad companies aren’t going to change, because they like money and don’t give a shit about users.
We’re stuck in a local minimum. It’s insane. It could be easily fixed if everyone just stopped doing the insane things. And they won’t stop.
Yet adverts on porn sites do operate as per our wish list:
* adverts are vetted by a human
* adverts are not allowed to inject JavaScript.
There have been a few interesting blog posts from businesses outside of the adult entertainment industry where they discuss just how work is involved in getting an advert approved on adult sites.
It’s a sad state of affairs when an adblocker is less required on porn sites than it is on Stack Overflow.
All major ad networks audit every single creative. The problem is javascript can change at anytime, and the publisher is the most exposed and also the most removed to be able to discover and mitigate. There have been some movements to whitelist the JS providers but volume is incentivized so most networks look the other way for now.
Adult ads are definitely not better and are served by even looser networks that allow anything. That industry has pioneered things like popunders, clickjacking, and monetizing every possible action on a window while serving as the primary vector for malware and browser bitcoin mining. I'm not sure what blog posts you've read but the only strict standards they would have is on getting paid.
Like everything, it depends on the sites in question. Disreputable adult sites aren’t going to be any better nor worse than disreputable sites of any other content. However adult sites run as a reputable business - of which there are many - most certainly do follow the points I described earlier.
What you’re effectively doing is looking at Source Forge and then arguing that Github, Gitlab and Bitbucket are all probably just as bad.
That sounds nice but is neither realistic or even sensible. There are other solutions like sandboxing to prevent access to features, it's not an unsolvable problem.
Billions? No single creative is seen by that many. In fact, with dynamic creative optimization (DCO) and all the optimization that happens, you can easily get creatives that are custom generated and only see by a few individuals or even a single person.
I wrote both comments. There are billions of impressions but a single creative is not seen by that many. The point is that the scale is too large to validate on the publisher side.
It seems to me there are two solutions to this problem:
* remove the ability for 3rd parties to abuse their automatic powers (ie disable their ability to inject JavaScript)
* or have a human manually vet every creative
The problem here is you neither want to control their access nor take responsibility for monitoring their access. So the blame equally lies with yourselves for not managing an easily exploitable vector of attack.
If this were any other system, eg VPN, security professionals would tear you a new asshole and point out just how irresponsible your lack of management is.
You’re only excuse here is greed and frankly I’m disgusted.
Major ad networks already vet every creative. The problem is javascript which can change at anytime. Banning javascript in creatives is not a technical problem, it's a business and politics problem. Same with just about every other issue in adtech.
I'm not sure who you think I am or why you're accusing me but none of this is down to a single person.
I think this comment[1] on the linked Meta question explains it pretty well:
> To the people confused why ads need to run their own Javascript (even ones that are just static images): The short answer is that Ad Networks do not and cannot trust website operators. They need to run their own JavaScript served from their own servers in order to verify that a real user saw the ad and for how long, and they can't trust the website operator to tell them. And these pieces of JavaScript tend to be more invasive and privacy-destroying than the website's JS because they care, far more than the actual website does, that the "user" is not a bank of iphones in a sweatshop in China.
Not just arbitrary JavaScript, arbitrary JavaScript where they can’t easily even see where it came from! Sheesh.
Could we require advertisers to sign their ad code to have a trail of where it came from, prevent tampering, and make it easier to pull the plug on bad actors?
The people bearing the costs of the internet ad economy aren’t the people in any position to do anything about it. So there’s very little pressure to fix anything.
Maybe if the US government started threatening to enact something like GDPR unless the a democratic industry gets its shit together.
Large adtech demand/sell side platforms do not want to remove these bad actors because they make money on percentage of spend. They are incentivized to increase volume and ad spend at all costs, and there is no regulation to stop them from doing otherwise by continuing to deal with shady companies and known malware techniques.
This is not a solution. JS still runs, it just has limited access to certain features.
You also need to somehow <iframe> the ad content (and serve it from somewhere else with the feature policy header set/attribute on the iframe set) or else sacrifice use of these features on your own site.
The solution is to make the ads inert. They do not need to run code.
Sites like StackOverflow require JavaScript to work (or at least, to work in a manner approaching interactivity). So, even someone who disables JavaScript normally, would presumably enable it in order to use this popular and useful site. Furthermore – and importantly – they place trust in StackOverflow not to abuse the privilege of executing arbitrary JavaScript. That is an entirely reasonable thing for a technically savvy modern web user to do.
By serving this ad with JavaScript not vetted to StackOverflow's presumed standard, StackOverflow has violated that trust. Thus the onus is on them, not the user, to remove the offending ad or risk damaging their brand.
Honestly, what you said is like saying "why would you ever not keep a hand on your wallet" after someone got pickpocketed in a nice restaurant. Reasonable people have reasonable expectations of safety in certain places which they trust to provide it for them. No-one should go around being constantly paranoid of pickpockets everywhere, no more than anyone on the web should be constantly paranoid of malicious JavaScript even on sites with established records of safety.
> So, even someone who disables JavaScript normally, would presumably enable it in order to use this popular and useful site.
I agree that StackOverflow is at fault here, but enabling JS is not a binary choice — "allow all JS on this site" vs "block all JS on this site" are not your only options.
Tools like uMatrix allow me to control JS coming from different domains on different domains independently. For example, on SO I have enabled JS from Stack Exchange and related domains, but not from Google or other snoopers.
"The ad is attempting to use the Audio API as one of literally hundreds of pieces of data it is collecting about your browser in an attempt to "fingerprint" it... Your browser may be blocking this particular API, but it's not blocking most of the data."
Seems like killing the audio is the metaphorical putting a finger in the dyke of serving arbitrary JavaScript to your users.
> we are aware of the issue.
> We're trying to sort out how to kill the audio behavior now.
Are you really aware of the issue? The issue people have here is not the fact that the ad is trying to access the audio api per se but that it is trying to fingerprint the users.
If you're "NOT okay with it", how about stopping ads completely until you resolve this problem? That should give a bigger impetus to solve it ASAP as the bottom line gets hit for multiple stakeholders.
This is not just ads, but about fingerprinting and tracking users somehow or the other by third parties. It's plain evil, and not a decent thing to continue foisting on your unsuspecting users after you've known it. Tell management to take an ethical stance and preserve the reputation of SO.
Probably not his call. By "we" he's probably talking about the engineering team, which in many cases is nothing more than a conduit for whims of the marketing and sales teams.
The only time they'd do that is if the marketing team decided that the value-add from taking ads off cancelled out the profit loss from taking the ads off.
I completely understand that it may not be his call. That's why I said "Tell management to take an ethical stance and preserve the reputation of SO."
Maybe he (or someone else in the team) has already given this as a temporary solution but it's been rejected. Since we don't know what's going on in the background, this suggestion being put on a public forum is still worthwhile. It could also help external parties (like HN readers) add more pressure in not letting this kind of surveillance continue just because the company doesn't want to stop making money while they're working on a solution or waiting for Google (or someone else) to help.
Every minute they delay cutting this off puts thousands of people in a position of vulnerability.
It's hard to read the obfuscated code and be sure what's being done with the browser environment information. This script seems to generate some hash and put in some global variables, presumably for some other script to consume. I don't know whether such scripts send it to a server, compare it locally to a previously-known value, or ignore it.
This is the actual problem at the heart of it all. And even if it were more profitable to take subscription fees than to serve ads, what's stopping you from "double dipping" and serving ads anyway?
ArsTechnica (obviously a very different site compared to SO) has an ad free subscription model where it also removed all trackers for paying subscribers. It's possible to do this in an ethical way. Whether the site publisher is interested or not is a different matter.
You think the NY Times, Linkedin, etc. is going to have the same response as StackOverflow? Good luck even getting in touch with someone who knows what you're talking about.
If LinkedIn (to choose a random example) advertises one of the perks of subscribing is that you won't be tracked, and then tracks you anyway, that's a story for The New York Times et al.
Sure. But my point was that the NYT is an example of a paid service that openly serves you a big pile of invasive ads, even if you're a paying subscriber.
Imagine if all the ads in the print edition were spying on and tracking your every move.
Very likely. I'd pay hundreds of dollars a year to Gogle if they guaranteed* me, with severe legal repercussions otherwise, that they wouldn't track me, or allow a single bit of my data, anonymized or not, leave their servers, or be used in any other way that wasn't for my own purpose.
Re-selling digital personas as commodities must be far more lucrative.
I actually wonder about this. SO's typical user is tech-savvy, and I would imagine many access the site with adblockers on (I do). So I suspect my value to the site in terms of ads is close to zero. I would happily pay a monthly subscription to know that the service will remain, given how much value I derive from it, if that gave me the assurance that they won't track me with ads/cookies/fingerprinting.
Their other income is from job ads, and I guess the value is that they have lots of data points about their logged in users (with scores high enough to imply they've interacted with the site a fair bit), in the form of what is posted, worth more than the aggregated list of websites that a user sees (as reported by ads).
I'd love to know more about this, as I have very little understanding of the economics of serving targeted ads. How much can they be making from ads?
I hear from multiple sides people reporting, to receive ads about topics thy only talked to friends about but never entered in a search engine.
Google has is currently as far away from their previous world famous "don't be evil" corporate culture.
Other examples are AMP where Google wants to make it harder to de-individualise URL's. This is being driven to an extend where Chrome on Android makes it harder to edit the URL.
Or games like Egress or PokemonGo, which in my opinion helps Google constantly update their WiFi SSIDs-To-GPS-location database.This database is rhen furthermore being used to track users location through a little permission called "WiFi Control", which also can not be found in the regular App Permissions settings entry.
To me WiFi-Control sound nothing like location tracking. But I have to admit, I am not a native speaker. Therefore I might be misunderstanding something.
Just out of curiosity, do those 7.5+ million accepted answers include those closed as duplicates? Because by far my biggest complaint is finding the exact question I have was closed as a duplicate and links to a question that is useless at answering my question.
In that case you can vote to re-open and perhaps even post a bounty. Although bounties tend to invite lots of low-quality, low-effort answers just on the off chance that they might be the top-voted one once the bounty runs out.
I feel you. I've taught myself programming between 13 and, well, I'm now 23; so by the time stackoverflow came around I had figured out how to solve things myself. When I have a question, it's usually either opinion-based (bad fit for SO) or not a common question.
I'd say 1:20 is a good estimate if I ignore answers that didn't read my question (which is most of them), but indeed the facts disagree.
Back then I didn't speak proper English, and how many questions were actually covered on SO in the beginning? It took some years to get to where we are, both for SO and for my English ;)
We could - but the network side isn't the problem. There's a lot of logging, user banning, etc. pieces that need IPv6 love first. We just haven't had the time yet.
There are network bits we'd have to evaluate heavily as well, e.g. firewall rules - basically the very limited benefits don't make it a priority, yet. When things change there, we'll do it.
Split horizon would point you at the same data center, rather than the writeable one. So that's more of a .local than a .internal. We discussed this, but ultimately the AD version we're on (pre-2016 Geo-DNS) it's not actually supported the way you'd need, and it's a nightmare to debug.
We'd consider it for a .local, when the support it properly there in 2016. Even subnet prioritization is busted internally, so that's a bit of an issue. Evidently no one tried to use a wildcard with dual records on 2 subnets before (we prioritize the /16, which is a data center) and it's totally busted. Microsoft has simply said this isn't supported and won't be fixed. A records work, unless they're a wildcard. So specifically, the <star>.stackexchange.com record which we mirror internally at <star>.stackexchange.com.internal for that IP set is particularly problematic.
TL;DR: Microsoft AD DNS is busted and they have no intention of fixing it. It's not worth it to try and work around it.
Those are 1220 bytes. I'm not sure what they'll compress down to, but it's still non-trivial and not near 0 (anyone want to run the numbers?).
The same pair of headers are 969 bytes for facebook.com and 2,772 for gmail.com.
I don't know what ours would be - since we're open-ended on the image domain side it's a bit apples-to-oranges compared to the big players.
When you take into account that you can only send 10 packets down the first response (in almost all cases today) due to TCP congestion window specifications (google: CWND), they get more expensive as a percentage of what you can send. It may be that you can't send enough of the page to render, or the browser isn't getting to a critical stylesheet link until the second wave of packets after the ACK. This can greatly affect load times.
Does HPACK affect this? Yeah absolutely, but I disagree on "negligible". It depends, and if something critical gets pushed to that 11th packet as a result, you can drastically increase actual page render time for users.
Oh I wasn't clear - I meant that for the same connection headers are not sent for every page but just references for previous values (see [0]). The initial page load is a different matter but that's part of the cost/risk analysis if you need CSP or HPKP (I agree it's not necessary and very easy to mess up).
> When you take into account that you can only send 10 packets down the first response (in almost all cases today) due to TCP congestion window specifications (google: CWND), they get more expensive as a percentage of what you can send. It may be that you can't send enough of the page to render, or the browser isn't getting to a critical stylesheet link until the second wave of packets after the ACK. This can greatly affect load times.
I wonder how much of the page can be rendered in 10 packets...
I explicitly try to ensure that for my sites the first 10kB sent (so less than 10 packets typically) is enough to render all the information above the fold. Anything essential should make it out in the first 2 packets for old TCP slow-start rules. (Lipstick and ads can arrive later, once the user is happy reading or whatever, IMHO.) Has been my policy since about the mid '90s!
Well if it wasn't for someone buying <star>.com back in the day, we probably could have them. Oh and then buying <star>.<star>.com after browsers banned that one, which led to RFC 6125 rule clarifications and restrictions.
Hey, I'm pretty sure that the first real domain name hack was sex.net, which as the proud owner of ex.net [PS: or was it sexnet.com, as we also have exnet.com?] caused some upset for a while, though mainly to disappointed one-handed typists I believe... B^>
BTW, did I blink and miss the "It really is all faster over HTTP/2, even given TLS" bit? My testing for my tiny lightweight sites close to their users (the opposite of what you're dealing with) is that HTTP/2 is slightly slower overall. Even with Cloudflare's advantages such as good DNS. And with the pain of cert management...
Use the Java applet below to search ExNet's main Web pages.
When the ``Status'' indicator stops flashing and says ``Idle'', type key words in the ``Search for:'' box.
The ``Results:'' box will show you the documents that matched your key words, the best matches coming first in the list. Click on any line in the ``Results:'' box, and that document should appear in a new browser window in a few seconds. When you are finished with that document, you can close it without killing your browser.
That code did search-by-word from (IIRC before Google existed, ie Netscape 2) right up until Java applets were dropped, across all compliant browsers AFAIK. It did roughly what G's live search now does.
I would imagine the more resources your page has, the more benefit you can get from HTTP/2 because of Server Push. So if you're comparing a tiny lightweight site, I'm guessing you can't benefit as much from Server Push.
I have relatively little that would benefit from push; basically a tiny hand-crafted CSS file that I currently inline because HTTP/1.1 and even HTTP/2 overhead for having it separate may be too high.
Yep - we're aware. I thought about putting in our Content-Security-Policy-Report-Only findings about what all would break, but the post was already a tad long. It's quite a long list of crazy things people do.
As the headers go, here's my current thoughts on each:
- Content-Security-Policy: we're considering it, Report-Only is live on superuser.com today.
- Public-Key-Pins: we are very unlikely to deploy this. Whenever we have to change our certificates it makes life extremely dangerous for little benefit.
- X-XSS-Protection: considering it, but a lot of cross-network many-domain considerations here that most other people don't have or have as many of.
- X-Content-Type-Options: we'll likely deploy this later, there was a quirk with SVG which has passed now.
- Referrer-Policy: probably will not deploy this. We're an open book.
> - Public-Key-Pins: we are very unlikely to deploy this. Whenever we have to change our certificates it makes life extremely dangerous for little benefit.
Is it possible to pin to your CA's root instead of to your own certificate? That would make rotating certs from the same CA easy but changing CAs hard (but changing CAs is already a big undertaking for big orgs).
