91–100 of 128 posts
www world really needs more www "browsers", particularly some more that do not implement javascript. Would it hurt to give users more choice and see what they choose? Only my opinion but there is much one can do without all the .js I certainly do not need Javascript to fetch some newspaper articles via HTTP.
Earlier quoted context omitted.
It's necessary if the NAT device doesn't support hairpinning. Unfortunately, historically many didn't, so users couldn't connect to other users on the same NAT using their public IPs, even with techniques that worked fine for connecting to other identical NAT setups elsewhere.
Is it necessary ? You could do a broadcast on the LAN if the public IP is the same.
Earlier quoted context omitted.
I'm sure someone could do better than this but here is a first try at a suitably informative prompt: $site_name wants to use WebRTC. WebRTC allows voice calling, video chat, and P2P file sharing, but can also be a privacy risk. We recommend allowing WebRTC only on sites that you expect to use such features on. [Link to learn more] Allow WebRTC for $site_name? Something like Flash's audio/video access prompt would als…
The preposition at the end of that sentence is unnecessary. Guessing you're from the midwest? :)
"sites that you expect to use such features on"
This means "sites on which you expect to use such features"
Not "sites where you expect them to use such features"
The preposition is key to having you be the one using, not the site. It doesn't have to go on the end, perhaps, and you could rewrite the sentence without that preposition, but simply removing it would leave you with an entirely different meaning.
I believe that WebRTC, just like JavaScript, should be disabled by default and enabled only on sites that you really trust and need it; and in the case of WebRTC, the argument is much stronger since its use-case is so specific.
And what should browsers prompt users with? "Would you like to use WebRTC?" What would that do to improve security for users?
So what you're really asking for is "can the web app know my non-NATed IP address if I'm behind a NAT and my non-VPN IP address if I'm behind certain kinds of VPNs"?
there's really no way in chrome to disable webrtc? That's amazing. edit: from the horse's mouths https://code.google.com/p/chromium/issues/detail?id=457492 edit2: you can install this https://chrome.google.com/webstore/detail/webrtc-leak-preven... and test here: https://diafygi.github.io/webrtc-ips/ though google sure seems to be dragging their feet on this so I'm sure they'll break this workaround soon
If you go read the bug you linked to, you can see that we added code to Chrome to specifically make this extension possible. It's in many CLs, but here is an example of one:
https://chromium.googlesource.com/chromium/src/+/7c98bab0212...
Further, we recently open sourced our own version of the extension and put it on github:
https://github.com/webrtc/samples/tree/master/src/content/ex...
And we intend to keep this advanced control, and perhaps more in the future, well-supported long-term.
Forum post from Dan Kaminsky, co-founder of WhiteOps[1][2]: "Dan Kaminsky here, my apologies for kicking up a ruckus. This is part of a bot detection framework I've built at White Ops; we basically are able to detect browser automation using resources exposed in JavaScript. Nothing dangerous to users -- or we'd go file bugs on it, which we do from time to time -- but it does provide useful data regarding post-exploit…
What problems are caused by browser automation? Slightly more on point, what issues might the NYT be seeing that detecting browser automation is the sensible solution?
Earlier quoted context omitted.
It sounds like the requests were a bug: https://github.com/EFForg/privacybadgerchrome/issues/431#iss... This looks like it's trying to exercise every dark corner of the user's browser in order to ensure that the browser is a real, eyeball-facing browser and not just a URL fetcher, PhantomJS/SlimerJS, or a clickjacking plugin being used to fraudulently click ads. I think it's easy to see both sides here: tools like th…
Yeah, I ran into a site a while back that was clever enough to spot that I wasn't using a browser. So I did, Selenium allows you to automate a real browser and capture the responses, hell if need be you can create a fake profile with Chrome and make it completely indistinguishable. EDIT: explanation, it was a video tutorial site for one of the technologies I use, each video had a download link but it had no way to ba…
Selenium allows you to automate a real browser and capture the
responses, hell if need be you can create a fake profile with Chrome
and make it completely indistinguishable.
I've used Selenium, but I just assumed that headless browsers were exactly: real browsers minus the UI.
Forum post from Dan Kaminsky, co-founder of WhiteOps[1][2]: "Dan Kaminsky here, my apologies for kicking up a ruckus. This is part of a bot detection framework I've built at White Ops; we basically are able to detect browser automation using resources exposed in JavaScript. Nothing dangerous to users -- or we'd go file bugs on it, which we do from time to time -- but it does provide useful data regarding post-exploit…
Honest question, why? What problems are caused by browser automation? Slightly more on point, what issues might the NYT be seeing that detecting browser automation is the sensible solution?
What problems are caused by browser automation?
Ad clicks.
Earlier quoted context omitted.
When I visit the NYT, it gets a full IPv6 address, non-NAT. Isn't this just as bad? Should we tell everyone to turn off IPv6 support?
If you want to hide the IP you're connecting from, and you want to use IPv6, then you have to find an IPv6-enabled VPN (or make one yourself with a cheap vps). The major use case for webrtc ip leak blocking is preventing leaking of rfc1918 IPs (or link/site-local IPv6 addresses) and preventing leaking of alternate LAN and alternate public IPs. For example, if you web browse through a VPN, this webrtc functionality wi…
Earlier quoted context omitted.
which it also attempts to enumerate common files such as virtualbox or vmware drivers via and off file://
Shouldn't it be impossible for a website to determine what files exist or do not exist on a local machine? That sounds like a serious security problem. It seems that no non- file:// site should ever be allowed to load a file:// resource, much less query the element for its size or error state afterward.
Those kinds of security issues are the low-hanging fruit that's largely been fixed by now.