Also, generally speaking, the way Safari implements this means that the extension passes on the block list to the browser and Safari itself implements the blocking. This means,
1. It is more private since the extension does not have access to your webpage.
2. It is faster because Safari can do it natively and it is not done in JavaScript.
Too true. I have Safari with 1Blocker / Wipr, through a PiHole that uses NextDNS for DNS resolution. All other browsers feel like wading through treacle. Whenever I'm forced to use Chrome on someone else's device I'm gobsmacked at how anyone could put up with something so slow and clunky.
I have contacted their support for Google Express before. It was because a delivery did not show up. Turns out I had selected the following day as the delivery day. Happy the mystery was solved (user error) I thank them. I get an email a few minutes later with a $5 credit for the confusion.
Another time I ordered a Space Pen with a clip. I got one that was without a clip. I contacted them and they said the one with the clip was no longer in stock. They refunded my money and let me keep the pen. Never asked for the refund.
I'm glad this was found independently and reported. While I was at PayPal I had started email threads about it but nothing was done. I am sure I was not the only one there who "discovered" this. For instance, even if you have 2FA you can add PayPal to Uber as if you never had 2FA.
The other big issue with their 2FA authentication is that it really isn't two factor. You can say you don't have the token and instead can answer security questions. Two factor is supposed to be something you know plus something you have. "Falling back" to security questions is basically just relying on things you know.
I would think that, if you have a big fraud-detection engine like Paypal's in place, 2FA isn't so much an enforced requirement for login, as it is a big fraud-signal when the user chooses to circumnavigate it.
Like any other fraud-signal, though, it can be countered with enough evidence that you are who you say you are--with security questions at a weak level (maybe enough to counter a 2FA token that was only set up a few days ago), or with demands for scanned photo ID at a higher level (if you use 2FA all the time.)
If there is no legitimate reason to circumnavigate 2FA, i.e. the S/N of detecting fraud by detecting circumnavigation is 1.0, why not just automate the anti-fraud enforcement and make the circumnavigation impossible?
Yes, I've contacted PayPal before and asked them for a user setting to be able to disable the 2FA fallbacks, but they don't really seem to care that much for security. I hope someone from PayPal Security team reads this and considers implementing this change.
I was also thinking that the community should start calling this type of implementation 2FAil, to give the companies a little extra 'shame peer pressure'... Anyone up for making a logo, heartbleed-style? :)
I've got to admit, this isn't humorous to me at all. Mostly just pathetic, mean-spirited, and ... gross. Yet another example of someone hating anonymously from the sidelines.
I think our industry would be better off with fewer people doing that.
This is pretty good. I wish there was a way to go directly to the comments on a post, but I don't know what UI would work for that.
A few other thoughts:
* Profile > Edit needs a cancel button. The only way to get out is to re-enter your username. Or maybe just make it go back to the old value if you enter blank.
* Long usernames tend to make the description line run off the screen and end with "...", which is a bit messy. Maybe a smarter truncation algorithm?
* Swiping left to right on a story seems to work inconsistently, but I'm not sure why.
Yours is my favorite, btw. I added an interesting feature to go beyond seeing what you've read--it indicates what you've already decided NOT to read.
I often find I choose to ignore certain posts but they often stick around so I reread the headlines. Pivit shows an orange indicator on brand new posts.
Re comments, I could add a feature to expand all if I get enough requests, but after some use I've found this to be optimal.
Is there are reason why this is a link to Google Plus which essentially links to GigaOM? The comments on Plus aren't what you would call top quality either.
That GigaOM article says "Google is phasing out the use of third-party code provided by the video conferencing technology vendor Vidyo", but this VentureBeat article says "Google will license Vidyo’s scalable video coding extensions for use in its free and open source VP9 video codec". Can these articles both be true?
"That’s why, moving forward, Vidyo actually wants to support WebRTC and open video codecs. The company is announcing Wednesday that it will contribute client-side scalable video coding technology to VP9, the next generation of Google’s open video codec. Vidyo will also cooperate with Google to incorporate some of its technology into enterprise versions of Hangouts."
As of now right now (~1374712460) there are two systems that are online: iTunes Connect and Bug Reporter. And both seem to use the cannot-be-killed* WebObjects. You can clearly see that in the URLs as they mention "WebObjects" and end in ".woa" (assuming it means Web Objects Application).
*I've no idea what WebObjects are but I've heard people poke fun at their mention. Would be interesting if someone had more details to share.
Side Note: If you are looking to install Command Line Tools and seem to be unable to install Xcode from the App Store. You can go to Xcode > Preference and install it. Screen shot from a couple of minutes ago: http://i.imgur.com/KEhjkE3.png
WebObjects is kind of like Rails, but 20 years earlier. (Seriously, it's actually very similar to Rails, in it's bones. I don't know if dhh had seen WebObjects, or they just both had seen some smalltalk mvc framework)
They inherited it from NeXT, and it seriously was really ahead of it's time originally. Hell, it was a technically competent and competitive web framework through, oh, 2002 or 2004, maybe even a few years after that. (Can you tell I used to develop for it?)
But it ended up not being a market Apple wanted to be in, selling a web development framework, and it didn't get much attention, it withered on the vine. (Even if it had... 20 years of legacy is not good for a web framework, it would probably still suck by now -- and who wants a proprietary rather than open source web framework, if they can avoid it?). But they kept using it internally anyway long after they stopped marketting it or selling it externally.
Anyhow, it's really hilarious if the legacy WebObjects part of Apple's web infrastructure are actually the parts that are still up. Hilarious in a pleasant way for those of us who used to use and love WebObjects back in the day.
I was brought in as a contractor in the last few months, so I didn't get much of an overview, but I wrote template code (each page, and each component of a page, had three associated files: .wos for 'scripting', .html for templating, and .wod for 'declarations' to tie the other two together).
It was streets ahead of anything I'd previously used (mainly PHP code with intermingled HTML), and led me to build my next major project using XSLT to provide some insulation between the logic and presentation.
That _could_ be a prime example of security by obscurity. Who would spend time looking for a WebObjects exploit if you can spend that time looking for a Rails exploit?
WebObjects is a web application framework. It's OLD old. It's about ten years older than Ruby on Rails, putting it on par with PHP and Ruby itself. NeXT made it and Apple decided to make it free. It was Objective-C and is now Java.
I used WO in the late nineties and it was way ahead of its time. Enterprise Objects (which morphed into Core Data) was an amazing tool for working with databases. Today it's pretty obsolete and it's not easy to find people.
It's not any older than Interface Builder and other stuff in the Mac OS dev toolkit, as all of that came from NeXT. I would guess though that it has not been maintained or updated.
I don't know about you, but I can't convert epoch time in my head and I don't know anyone who can. What's benefit is there to posting epoch time instead of in ISO 8601 format?
Yeah, I noticed the WebObjects apps were back quick and first. With all of the iOS 7 bugs filed and the App Store in active use, I'm not at all surprised that they are too big to die for the time being. As for the rest of it, my money is on some Ruby descendant, based solely on the fact that all of the Passbook sample code was Ruby based, with a Sinatra app being the server and a signing gem bundled. I think some of Mavericks server utilities are Ruby based, too.
Isn't the developer portal written in Java too, probably with a mix of frameworks for different components (it certainly had a heterogenous feel on the front end)? I seem to remember some of the signon urls had .woa in them, and one of the former Struts developers mentioned a vulnerability which sounds like a likely candidate:
I think a better word would be "refuse", as it more accurately portrays the situation. It too is not perfect though, as your "refusal" can still be ignored.
Actually, in this case "Limit" is perfectly accurate. The only result of checking this is that the application must call advertisingTrackingEnabled before using the identifier.
If enabled is NO, then the developer can use the identifier for "frequency capping, conversion events, estimating the number of unique users, security and fraud detection, and debugging". Notice that compliance with these restrictions is almost impossible to determine.
Ugh, I hate these. Instead of disabling it at the OS level, where they should do it; they create a "let's give unethical companies another bit of information" option.
I've been making the Android / iOS argument for over three years. Any forward projections are just opinion obviously.
I have a particular talent for spotting negative positions in stocks and trends in general. I'm not trying to prove that I do, take my word for whatever it's worth to you. In equities I've derived it from the Graham-Dodd-Buffett approach. I've found it exceptionally easy to spot when to short stocks by reversing the Graham Dodd approach (it works for spotting undervalued equities, and it works equally for spotting overvalued equities, I just happen to be good at that side of it).
On the technology side, if you understand Apple's business model, and you understand how technology markets work toward consolidation around standards, and then you apply the context of what Android is and its vendors / support / ecosystem (and whether it's of high enough quality to be good enough for that 80% to 90% of consumers, to rule ala Windows) - the rest is obvious, it lays out a momentum line that can't be stopped.
There are exceptionally painful consequences to Apple losing market share that very few are pricing into things. The mistake I see often is linear thinking on market share to profits; eg if Apple is making $30 billion on 20% market share, said people then think Apple could make $15 billion on 10% market share (when in fact there are numerous destructive penalties for falling below thresholds in the market, regarding developers / apps, music, media, consumer perception, negotiating position with suppliers, stock price falling and losing key employees and on and on).
"Samsung, by comparison, revealed that it has sold 21.25 million smartphones in the US between June 2010 and June 2012, along with 1.4 million tablets. (Keep in mind that the smartphone number only included devices at issue in the trial, not Samsung's full lineup.) But even when you only look at Apple's data from those same quarters, the differences are stark—the company sold almost 63 million iPhones, 34 million iPads, and 25.3 million iPod touches during the same period. Even the weakest link of the iOS family—the iPod touch—is selling faster than a large chunk of Samsung's portfolio."
Or the risk of offending the biggest source of funding? Why does being tracked be the norm and you have to explicitly say don't track me? In real life you don't have to go to a government agency and register "I wish to not be stalked". What is wrong with saying it is the user's choice that they be tracked. Default is don't because that's how real life is.
(If you really really really care about a user's choice like you say you do then make the user make a choice. On first launch get the user's choice and refuse to work without being told what they'd prefer.)
Edit 1: I read the W3 draft on Do Not Track and seems like there is a section for "Explicit Consent Requirement".[0] Although whether the committee is influenced by corporation in way that the industry is tasked with policing itself is a different topic altogether.
Edit 2: Brain Smith from Mozilla responded with websites ignoring the flag if set by default. That's what Yahoo! did.[1] But that's the problem with any honor-based system.
> Or the risk of offending the biggest source of funding?
I (a Mozilla employee) can understand why people worry about this, because there does seem to be a conflict of interest here. But, I've never seen anything to indicate that we consider Google's payments to us in any security/privacy decision.
DNT is not the ultimate solution to tracking on its own. It is part of a solution.
Consider this:
Let's say you go buy a box of doughnuts and take it to work, open it, and leave it open on a table next to your desk. Some people will think "Hmm, I want one of those doughnuts but I'm not sure if it is OK to take one, so I won't" and other people will just assume that it is OK to take one. (Why else would there be an open box of doughnuts? And/or isn't it better to ask forgiveness than permission?)
Let's say you write "Do NOT take these doughnuts! They are mine!" on the box with a big fat marker. If somebody were to take a doughnut, they would be clearly in the wrong in that situation, according to any kind of mainstream social convention.
Lots of people will say that it is wrong to take a doughnut without explicit permission. But, many, many people see the situation as being open to interpretation.
Now, let's say the doughnut shop pre-printed "Do NOT take these doughnuts! They are mine!" on every box. You might argue that that is the same thing as the hand-written sign. But, I would bet that the pre-printed message would get drowned out as people would normally share doughnuts out of these pre-printed boxes: "Just ignore the box, they all say that; it doesn't mean anything." The pre-printed message becomes less and less meaningful, even though the words are clear, unambiguous, and explicit. And, worse, you may be discouraged from writing your handwritten ""Do NOT take these doughnuts! They are mine!" message on the box because, well, the box already says that. Effectively, that message pre-printed on the box is harmful, as its meaning is in the eye of the beholder--just like the open box sitting on the table with no message written on it at all.
Do you see how that could possibly be problematic? This is the problem that Sid and others at Mozilla are trying to solve. "DNT: 1" means it is clearly wrong to track this user because they've gone through special effort to tell you they don't want to be tracked.
Consider a world where your box of donuts WILL have donuts taken out of it, even if the box is closed, as soon as you walk away from the donut shop. As soon as you hit just about any website on the internet today, YOU WILL BE TRACKED. There's no maybe here, it's a virtual certainty. So this makes it accurate in your analogy.
In this world (call it Doughnet?), it makes sense to have the donut shop print a sign on the box in the event that the sign is sufficient to prevent people from ambushing you and taking your donuts. You could simply ask the donut shop to give you a blank box if you wish to have your donuts taken (opt-in donut sharing) rather than asking them to give you a box with the sign (opt-out donut sharing).
Nobody expects to have their privacy maliciously and constantly invaded. This is emphatically WRONG behavior. And so broadcasting to all parties that the user of your browser is willing to be tracked by default is precisely the wrong thing to do. I don't care what your motivations are, it's just wrong, period.
Back to my analogy: I never said it was OK to take a doughnut without explicit permission. I just said it was obviously bad to take one when there is an explicit message saying it is bad to take one.
That is a very good question/suggestion. It is a good idea to make the option easier to find. I definitely think it is important to educate more people about the issue.
There may some validity to the idea that "the journey is part of the gift"--that is, the harder the option is to find, the stronger the signal of user intent. But, I don't think the current balance in Firefox is correct. I'm not sure that a checkbox at startup is the right answer either. if you ask on Mozilla's dev-privacy mailing list [1], you might get a response from some somebody that has thought about it more than me. Then I'll get to learn about it too.
the user don't care at that time - they probably have something more urgent to look at the first time they run their browser, and if you bombard them with questions, it gets annoying.
I agree with the default being ON (that is, DNT is turned on). The analogy with the doughnuts and pre-printed message isn't quite accurate in this case, because it is _clearly_ a better choice to not have tracking done on the user, whilst with a box of donuts, its not always clear cut whether sharing it or not is the right thing to do.
Every OS comes with a browser other than firefox by default (except certain flavours of Linux, but they could make the choice part of the install process). If the user needs to look at something on the internet right now, they won't go searching for firefox, downloading and installing it. Having one simple checkbox that takes half a minute to decide on won't make installs take all that longer. Or just display a configuration page the first time the browser starts up with a "you can set all these later too from <here>, btw" message.
Forcing the user to choose something and refusing to run if they don't, even when it's a non-essential setting like this? That's a terrible idea. I'm annoyed enough when browsers ask me if I'd like to set them as default; the last thing I want is a 10-page questionnaire of the browser's settings.
Also, generally speaking, the way Safari implements this means that the extension passes on the block list to the browser and Safari itself implements the blocking. This means,
1. It is more private since the extension does not have access to your webpage. 2. It is faster because Safari can do it natively and it is not done in JavaScript.