13 ms·
Can ads on a page read my password?
- allana 7y agoSounds like a great reason to block ads, if not all 3rd party scripts.
- nixpulvis 7y agoThe whole Web 2.0 is a mess. https://nixpulvis.com/ramblings/2018-08-11-web-shit-point-oh https://nixpulvis.com/ramblings/2018-08-11-web-shit-point-oh
- allover 7y agoEven imagining a world in which all the major browser vendors had agreed to constrain browsers to a pure HTML+CSS+flash-like-extension-free web, someone would've eventually come out with a heavily funded 'next gen' browser with their flash/silverlight equivalent, and we'd either be in proprietary-land, or right back here with an open JS equivalent, post-backlash. Ship sailed and always would have.
- nixpulvis 7y agoAnd that's why we enlist regulators to protect the consumers. This isn't new, you're right.
- gridlockd 7y agoWhat are you gonna regulate here, ban third party code? Good luck with that.
- nixpulvis 7y agoWhy do you assume regulating = banning?
- gridlockd 7y agoWell, what's the alternative then?
- nixpulvis 7y agoElect sane and involved policy makers to keep a watch on the market. Impose regulations that make it harder to exploit the consumer, and hold those who break these policies accountable. I suppose the whole ban vs regulate issue is a matter of granularity. Regulation does impose a set of banned practices, but it's not like you make it out to be, where all 3rd party code would have to be banned. The main issue is that we need to agree on what we are actually capable and interested in protecting, in an insanely fast moving industry. This is why motivated and educated policy makers are crucial to the problem. There's still to this day no where near the level of discourse on this subject that's needed happening in places with power to make a difference. Just like in the early days of the gold rush, I'm sure you could find countless cases of criminal shovel sellers. But given the current ecosystem, this doesn't surprise me sadly. We (in the US) are locking kids up without parents for crimes they didn't commit. I suppose abusive or illegal ads aren't my biggest concern.
- gridlockd 7y agoI'm sorry, I meant to ask: What's the alternative to banning third party JS? What's the actual regulation that should be enforced here? Do we ban specific behaviors of programs for third parties, but allow them for first parties? Make businesses pay for all the auditing? Let me just say: I don't know what harebrained regulation would come out of this, but I'm pretty sure I don't want it. > Elect sane and involved policy makers to keep a watch on the market. That's not a solution, that's a fantasy scenario.
- nixpulvis 7y agoI'd like to see restrictions to what terms of service can permit. For example, it's one thing for me to be giving the 1st party some legal rights to collect information about me, it's another thing to allow essentially untrusted 3rd parties to collect as well. Some limits must be in place. If this means some services are no longer viable because they can't make ad revenue, then maybe that's a good thing. Nothing is free, and we still live in the Wild West with companies getting away with monetizing our information behind our backs to subsidize the service. It's one thing to "pay" me for the time I watched your ad, it's another thing to "pay" me for a profile of my activity on the site or sites, which has enough information, generally, to uniquely identify me, and contains demographic and personal information determined by black boxes. My point here might simply be, if it's my information, I should be entitled to know how it's actually being used. But the first action I'd hoped to see is to make devices like the Amazon echo, and google home illegal. > Probably the clearest example of a place where there's a reasonable expectation of privacy is in the home. A person doesn't have to be a homeowner for the law to protect that expectation; tenants who rent their homes also have a protected right to privacy. Moreover, invasion of privacy doesn't just mean that someone physically enters a place where a person has a reasonable expectation of privacy. It can also happen if someone uses electronic equipment to monitor or record what someone is doing in the home. [1] This also goes for guests of your home, so as far as I'm concerned, Amazon (or my friend, or both) are/is breaking the law whenever I enter a home with one of these things installed. The regulation should demand a Amazon (in this example) to explicitly state how they are protecting my rights given the presence of an active microphone in the home. As things stand they are clearly not respecting our privacy. Even Apple, who makes a point about how "Hey Siri" works isn't completely off the hook. I'd be interested in talking about Japan-esque laws requiring a sound to be played when Siri is activated, much like how a shutter noise must be played when a photo is taken. The point here is, it's MY LIFE, I should at least know what's being done with it. 1: https://injury.findlaw.com/torts-and-personal-injuries/what-is-the--reasonable-expectation-of-privacy--.html https://injury.findlaw.com/torts-and-personal-injuries/what-...
- paulgb 7y agoBack before HTTPS was prevalent, as a proof of concept, I set up a DNS server to redirect Google Analytics domains to an MITM server that added a keylogger and added some HTTP headers to tell it to cache it as long as possible. The result was a keylogger that persisted on most sites (anything with GA), even after I connected to a non-compromised DNS server. Fortunately this is no longer possible because of HTTPS, but I was able to convince some big sites to switch to HTTPS because of it.
- jjnoakes 7y agoHow did you get clients to use your DNS server? Was it on a network where you controlled the router, or did you set up a WiFi base station that folks blindly connected to in public, or some other way?
- pseudosavant 7y agoI'm pretty sure you could do it with just ARP spoofing/poisoning (https://en.wikipedia.org/wiki/ARP_spoofing https://en.wikipedia.org/wiki/ARP_spoofing). No need to control any other node on the network.
- paulgb 7y agoYes, I did it on my own network at the router level as a proof-of-concept. I didn't actually use it on other people, but the idea is that a malicious public network operator could do so and effectively install keyloggers on dozens of people per day.
- pseudosavant 7y agoThat is pretty sinister actually. Totally something you could do anywhere people get 'free' wifi. If you look at the second answer (https://security.stackexchange.com/a/214877/12942 https://security.stackexchange.com/a/214877/12942) it looks like the GA code Goodreads is using specifically will use http:// http:// instead of https:// https:// if the current page is http-only. So that this would still work. There isn't a good reason to get third-party resources via http if https is available, even on non-https pages.
- ceejayoz 7y agoCapital One's site (which includes a login form) calls out to DoubleClick, Facebook, New Relic, something terrifyingly vague called xg4ken.com, and about a dozen other third parties. One targeted compromise of any of these scripts would be catastrophic.
- varenc 7y agoFor an example on how to do this with fewer compromises on security, check out Dropbox's homepage. They also call out to a dozen third parties, but the entry point for all the JS is a sandboxed <iframe>, mitigating the fall out if some of that JS becomes malicious.
- kevin_thibedeau 7y agoA company with Dropbox level money should be able to write all of their front end code. It's disgusting that few top 500 companies do.
- varenc 7y agoI don't think any of the third-party JS is for functionality. Many large companies call out to 3rd parties not because they don't want to write code, but because they're using marketing services so they can do things like re-target users for ad displays on other websites. (also many top N companies do use 3rd party code, like React, but they usually re-host that themselves)
- CamperBob2 7y agoDropbox doesn't appear to have the strongest developers on the client side, so perhaps that's true on the front end as well. I still get messages along the lines of, "Your hard drive is full. Dropbox cannot synchronize until you free up some disk space," with 4 GB free, even though many users have complained loudly about that for years. The Dropbox client was also causing weird problems with dropdown menus in MS Office applications for a long time, which took forever to track down. That at least appears to have been fixed now, although I can't (or perhaps don't want to) imagine how it happened in the first place. Dropbox does hard things, HN conventional wisdom notwithstanding, and they do them reasonably well. But they can be very slow to recognize when they're doing something wrong.
- BitwiseFool 7y agoI was already blocking ads via uBlock Origin, but now I may start blocking third-party scripts by default.
- munk-a 7y agoI switched into a block all scripts by default web stance a while back and am continuously amused by how operable different sites are, some degrading relatively gracefully, some just going white screen (usually SPA of some sort) other sites go totally wonky when they find themselves unable to rewrite the DOM and style rules to render the page as they want - sorta close to that old occurrence when CSS would fail to download and you'd have a giant <ul> block that was being restyled as a menu... but far more disappointing because there is really no reason to push styling into JS and so many out-of-the-box responsive style frameworks at this point.
- ceejayoz 7y agoThe really fun ones are the ones that work better with the JS disabled.
- danieldk 7y agoI use uMatrix on Linux and am continuously surprised how many blog-like websites could be plain HTML/CSS, since they just have text and images, but don't show any content at all with Javascript disabled. More and more often I'll just go back where I came from and don't bother with these sites anymore.
- reilly3000 7y agoThat is the whole point of safe-frames, which are default in DFP. >While SafeFrame shares information with ad content served to its API-enabled iframe, the publisher chooses what to share and can protect sensitive consumer information like personal email addresses, passwords, or even banking information. Docs for DFP: https://support.google.com/admanager/answer/6023110?hl=en https://support.google.com/admanager/answer/6023110?hl=en Spec: https://www.iab.com/guidelines/safeframe/ https://www.iab.com/guidelines/safeframe/
- mceachen 7y agoFor people not in the adtech space: DFP is DoubleClick For Publishers, who initially served banner ads and were bought by Google in 2008. https://en.wikipedia.org/wiki/DoubleClick https://en.wikipedia.org/wiki/DoubleClick
- phkahler 7y agoTechnical measures can not be required to cover security holes. The holes must be closed. Otherwise it falls on users to audit all sorts of stuff they dont understand - and by users you can include developers.
- gridlockd 7y agoThis is not really a security hole. It's the intended behavior. Web developers (should) know that they are exposing all user behavior to the third-party code they bring in. The solution is to "no do that", but developers tend to choose convenience over safety, as do their clients, as do their clients users.
- deleted 7y ago[deleted]
- munk-a 7y agoI really wish awareness of this reached a wider audience, third party advertising is a terrible blight on the web that has been allowed to grow and fester - it supplies no value and compromises both browser security and our peace of mind - being bombarded by these things constantly is training most of us to ignore a lot more and focus on short focused bursts of information... IMO (and this is really deep into opinion) this has slowly been contributing to the lack of attention spans and un-inquisitive response most people have when things on facebook just straight out tell lies. Web-advertising has such a feeble value for the cost it's exacting.
- giancarlostoro 7y agoIf ads were just images / text links I wouldnt ever bother using an adblocker. But because pop ups and insane amounts of JS abuse, auto playing videos and browser exploits I just cant stand ads. At least ads in magazines flow with the content.
- panarky 7y agoIf you go to the Chase login page, it loads js from demdex.net. DemDex "captures behavioral data on behalf of Websites and advertisers and stores it in a 'behavioral data bank.'" uMatrix blocks it for me, but this shit could harvest banking credentials?? https://imgur.com/a/oTm09k2 https://imgur.com/a/oTm09k2
- type0 7y ago> this shit could harvest banking credentials?? It's not that it happens or could happen, the problem is that when credentials are leaked the user gets all the blame: "not our fault, you probably had a virus on your device", and most users will believe it.
- giancarlostoro 7y agoWe need a sort of GDPR law but not as... Broad or unclear as it is. The problem is big tech companies would never draft a bill that puts them in a bad spot. For the People has become For the Corporations and it really does suck.
- SilasX 7y agoStupid question: why not make password-marked fields something that JS engines simply can't read from? I imagine it would stop you from client-side warnings of password insecurity, but is there a bigger problem?
- ceejayoz 7y agoIt would kill any site with an AJAX-based login. Twitter, AirBnb, Facebook, Google, Apple...
- noodlesUK 7y agoI imagine it would be pretty easy for the js to just remove the element from the DOM and replace it with a similarly styled input if all we are doing is stopping it reading the contents of the password input
- lucb1e 7y agoI use JavaScript on some password fields for client-side password hashing (reasoning: https://security.stackexchange.com/a/201099/10863 https://security.stackexchange.com/a/201099/10863), but I agree that this might be a useful thing. I can think of a few ways this could work: - Blacklist or whitelist access: <input type=password nojs> or <input type=password allowjs> - Specifically set a method that is called upon form submission: <input type=password onsubmit=hashPassword> <script>function hashPassword(value){ ... }</script> The catch here is that the browser would have to error out on reassignment of the hashPassword global variable, since that is what malware would do. This sounds easy, but it might be quite a bit more complexity for the browser's JS engine, since it has to check every assignment in the global scope against a list of functions that are used for password fields. - Only allow access from the code path starting with the form's onsubmit event, so <form onsubmit="return validate(this)">. The catch here is that most modern websites do $("#myform").onsubmit=function(){...} which any malware could do as well, so that would have to be disallowed. A lot of devs wouldn't be happy about that. Though for backwards compatibility, the opt-in method would probably be the only candidate for actual implementation in the foreseeable future.
- moltensodium 7y agoYou can't browse the web securely if you're being served third party ads. I'm not sure why this is considered acceptable and why the onus is always on the user to find and report the "bad" ads that a site owner has no control over, but it's really stupid. I spent years browsing the web before there were any advertisements at all. There is no need for this garbage despite how many Stanford grads tell you it's totally necessary.
- malms 7y ago> I'm not sure why this is considered acceptable Because ads make money to all parties except the user.
- deleted 7y ago[deleted]
- indigo62018 7y agoHow about side channel attack (such as meltdown and spectre) from ads? Is it possible?
- zie 7y agoNormally yes, but most browsers have mitigations in place that prevent this from happening, for some degree of prevent. But browser mitigations, plus OS updates and Intel/AMD firwmare updates, for machines that stay up to date make the specific Meltdown/Spectre attacks mostly not a thing in JS(in the browser). That said, Javascript(in browser) and Security are basically 100% opposites. If you can execute JS in a browser, you can do whatever you want to that page in the browser.
- zzzcpan 7y agoThere is a problem with mitigations in web browsers, the only practical problem they are targeting is a hypothetical situation of a 3rd party script running in a sandboxed iframe, but almost none of them do! They don't need side channels to steal anything, they are not isolated. And the only acceptable use for a sandboxed 3rd party iframe is to block it by default.
- zie 7y agoWell, I was going to say more on the subject, but didn't want to get flamed by JS lovers. I did say "If you can execute JS in a browser, you can do whatever you want to that page in the browser." I don't disagree with your point, but there is another perspective that the mitigations aim to stop, which is cross-tab/window data gathering (and cross process), which is most of the point of Spectre and friends anyways, which is stealing data from some other process, not the process you are running under. Stealing from your own process is easy. Stealing from another process is supposed to be hard, and stealing from the kernel is supposed to be impossible.
- JoshMnem 7y agoumatrix makes it easy to disable all JS or all 3rd party JS: https://addons.mozilla.org/en-US/firefox/addon/umatrix/ https://addons.mozilla.org/en-US/firefox/addon/umatrix/ You can combine it with custom CSS through stylus: https://addons.mozilla.org/en-US/firefox/addon/styl-us/ https://addons.mozilla.org/en-US/firefox/addon/styl-us/
- harry8 7y agoDo this. Do pi-hole too. But we shouldn't have to. If enough of us do maybe they'll stop all this 3rd party crap. It shouldn't be up to users to audit every damn 3rd party url to protect themselves. You went to a single url the publisher of which should be completely responsible both morally and legally for all content. The end.
- gridlockd 7y ago> It shouldn't be up to users to audit every damn 3rd party url to protect themselves. You went to a single url the publisher of which should be completely responsible both morally and legally for all content. The end. In other words, shut down all businesses that rely on third party advertisement. Got it.
- apexalpha 7y agoBusinesses used to rely on pop-up ads too, before browsers started to ban them. If browsers ban JS in ads, HTML based ads will rise in value.
- gridlockd 7y ago> If browsers ban JS in ads, HTML based ads will rise in value. How are you going to detect what third-party JS is an ad? That's basically the job of an ad blocker. Do you expect Google to ship an ad blocker that blocks ads of its competitors? That'll be a great antitrust lawsuit.
- harry8 7y ago
- perl4ever 7y agoIt occurred to me that I, and others, are trying to deal with advertising the wrong way. It's a waste of time to try to filter out ads per page. There needs to be a way to search pages without ads (without javascript ads anyway) and to show pages without links to pages with ads.
- 33Backpack33 7y agoIsn't most OS's now blocking read access to text fields labeled as "password"? I'm pretty sure MacOS does this now.
- saagarjha 7y agoNot in the browser.
- LeonB 7y agoIf you make sure that login/registration pages have no ads, that's not enough to be secure. One example: you've probably clicked the "login" (or register) link from a page that does have ads, and a malicious script could've hijacked that click and presented you with a perfect replica of a login (or register) page, and then captured your input. And I'm sure there are many other such tricks.
- musicale 7y agoTL;DR: yes. They suggest mitigating this by putting ads in a sandboxed iframe (unlikely and probably not foolproof) and not having ads on a login page, but ads can probably still steal your credentials. It should be obvious that loading untrusted third-party content compromises security, but apparently that is unimportant to sites that use third-party advertising services.
- Animats 7y agoWorse, "Google Backdoor" (a/k/a "Tag Manager") lets third parties inject Javascript into your web pages. You can't even put Google's stuff into an IFRAME to sandbox it.[1] The Evil Empire does not like to be contained. [1] https://adsense.googleblog.com/2011/06/clarifying-our-ad-implementation.html https://adsense.googleblog.com/2011/06/clarifying-our-ad-imp...
- andrerm 7y agoAnd now Google staring its move against ad blockers by first restricting them and then forbidding (they will deny). But it's for performance and speed because ad blockers are so bloated /s. And if course Google can't do evil because "Don't do evil" /s
- phkahler 7y agoSo the solution is to disable JS?
- mirimir 7y agoBasically, yes. I use NoScript, blocking everything by default. If a page doesn't load, I enable stuff until it does. I've been doing this for years, so I know what's generally needed. But for Goodreads, I'd be hosed as soon as I allowed the site itself: > In the case of goodreads, their HTML contains javascript from the ad provider. Specifically, lines 81-145 of the HTML document returned by https://www.goodreads.com/ https://www.goodreads.com/ read: However, it's more or less readable without allowing any scripts. So hey. So was that a way to work around ad blockers?
- ErikAugust 7y agoA founder of a “customer experience” service cold-messaged me once. I came in to see more about what they were doing, and they interviewed me a bit. As far as I could gather they provided a script to their customers that added event listeners to everything on the DOM and sent it to their servers. As far as I can tell, they were going fast and loose. They weren’t interested in me, but I must say I wasn’t interested in them either.
- skygazer 7y agoMany years ago, I was a software architect at an online travel company. Marketing kept asking me to approve third-party hosted tracking scripts walking the DOM looking for tracking tags at every step on our purchase path. I objected on the billing page, simply because I couldn't guarantee the safety of credit card numbers and customer data, but said it would be okay if we reviewed and hosted their js statically, but the third parties always refused. Perhaps I overreacted, because at the time, the e-commerce industry didn't seem to care about the risk. Do they now? I hope OWASP/PCI/GDPR have since developed opinions about third party hosted js on sensitive pages.
- he0001 7y agoRegarding the answer: >It's worse than that. Web performance tools and similar not only read your credentials but they read the credentials you type and then delete. Very nasty. You might be able to get away with not typing, always pasting your credentials. But the javascript has access to your DOM so it can just read every element. The only way to stop that is not to use credentials but to use oAuth and hand you life over to Google. What could go wrong. What’s the technical explanation how OAuth is safe in this context? If the DOM is accessible wouldn’t other things be accessible?
- L3viathan 7y agoThe authentication happens on a different site (the Google login site) then, and you only get back a token. The worst the ad could do is steal your token then, which will only be valid for a little while.
- londons_explore 7y agoPick a random webpage with ads, right click, and "inspect element". You will see the ad is rendered in a sandboxed iframe. It's true that the ad-network can usually run in the context of the main page, but the ad itself cannot. The ad network is typically fairly trusted - they are profitable businesses with a lot to lose to lawsuits if they store or leak your password. It's the ad itself that you shouldn't trust - anyone with $1 can submit an ad. And that's why it's sandboxed.
- krageon 7y ago> a lot to lose to lawsuits if they store or leak your password. This has been demonstrated to be wrong (see: every time there's malware on an ad network).
- londons_explore 7y agoThere has been no instance of malware on an ad network (that I know of). The malware has been in an ad creative, and those are sandboxed. The malware has usually exploited weaknesses in the browser, but if there weren't browser exploits, it still wouldn't get access to the host page. Such browser exploits are getting harder to find with things like per-domain processes isolation in Chromium based browsers.
- krageon 7y agoThe only thing creative here is the imagination that the ad network is not responsible for the content it serves, though I recognise we may just have fundamentally different outlooks on responsibility. If that is the case, I feel like discussing it further is not going to help either one of us.
- zzzcpan 7y agoWe all know this is not generally true. Ad networks will even explicitly allow advertisers to inject their own unsandboxed js. And so will publishers. But hypothetically if this was true still doesn't make a difference, adtech is pretty negligent of security.
- ypcx 7y agoRunning uBlock or similar is now a part of a basic web browsing hygiene. There used to be starting projects which used cryptocurrency or some other token system to allow you to "load" your browser with credits, which then would get auto (or semi-auto) voluntarily distributed to the websites you read, which support this mechanism. But I think they haven't caught on. But essentially, I hope they come back. In the mean time, I'm still waiting for a reasonable solution to block advertising and tracking scripts on the mobile - as e.g. I think no sane (and informed) person will use a closed source browser, e.g. Brave.
- pllbnk 7y agoAssuming you are using Firefox on Android, you can use uBlock Origin or almost any other extension as you would on desktop.
- BrendanEich 7y agouBO works on desktop Brave too (a lot of redundancy but it adds 1st party blocking features) and we will keep it working, whereas Google seems intent on breaking it with Manifest V3 extension API changes.
- BrendanEich 7y agoBrave is all open source. Why did you think otherwise?
- ypcx 7y agoI was trying to find its source once and I couldn't. Thanks!
- croh 7y agoSadly google/facebook/amazon only cares to increase speed and loading pages fast. many new standards are being developed for this. but not about user security as ads is their primary business.
- gridlockd 7y agoI would like to point out that, despite this arguably catastrophic situation, it's not much of an issue in practice. Stealing credentials through third party code is a relatively expensive attack. It has to be engineered for a specific site and then it needs to pass the auditing of the vector (i.e. the ad network, or the developers). Once the attacker has achieved that, what do they get? The credentials for most sites are worthless. Of course some users might use the same password on multiple sites, but they had it coming. Those sites that do have valuable credentials also have heightened security measures. If your bank is serving you ads on the login screen, perhaps you should use another bank.