subudeepak

This is consistent with expected behavior from my point of view. A bug in safari's controls would not infect the website. The site clearly sends a policy and safari clearly follows it. Perfectly sensible behavior.

Of course CSP does not allow a way to say -> browser controls are okay. Hence, a debate is quite welcome on whether such a specification is needed.

Secure boot is in no way bad :-) Ofcourse, it must in fact be the first point on any sane security checklist.

And one of the most common attacks aka. malicious firmware is prevented by using secure boot.

Many other classes of attacks like forcing the microcontroller to delete all its data, opening up the debug JTAG port of the microcontroller, preventing the log of certain security events etc. can be achieved with the right settings.

Though these are just remote possibilities with high levels of complexity, so is changing a production design of a board.

Hardware attacks cannot be prevented by secure boot...

It looks just like this :) http://s289.photobucket.com/user/stranger205/media/battery_s...

I understand what you mean. But in my remote, the batteries are not arranged in serial; they are arranged in parallel. That being the case, my remote can see both terminals of a given battery. Hence, I fail to see, as to why the mechanism cannot be implemented as part of such devices..

The same applies to my wall-clock (which uses a single battery)

Thanks for sharing. I was wondering, why do we need the sleeve ? Can the voltage boosting module be part of the remote itself ? Isn't that what a dc-dc module does ?

What kind of email account do you need ?

> For disposable addresses you have mailinator.com

> For normal ids, there are quite a lot from mail.com .. or you could go to yahoo or outlook ...

> Your ISP must have provided you an id to you too.

All of them work.

I still don't understand HN's algo. The current 1st post has 301 points in 7 hrs while this post has 301 points in 3 hours but is in the second page ??

Really made me laugh. Service to bridge a gap between a customer and a customer service :)

But yet it is brilliant !

:) Agree on that ! [Have not used any office in a while now - Markdowns have been sufficient]

Does not look like something they would have done intentionally. Explanations will come soon I guess.

These are all affected repos ! Damn !!!

Even apache openoffice is using SourceForge for their downloads. There are quite a lot of s/w there at this moment.

Any other projects affected ? Would be nice to start a list of all affected projects. This could also be a case of targeted attack on the gimp account.

You are not paranoid. You could use Chromium which has relatively fewer connections to google servers. You could also look at alternative browsers that have been forked from the chromium project with an emphasis on privacy.

For example: WhiteHat Aviator.

If you are comfortable changing settings of the browser, you could disable most of the google connections from the browser. [The first things I recommend changing is the search URL, disable auto-completion, bad site checking etc.] Then you have the do not track header ..

Of course, if browsing privacy is your biggest concern, the safest browser is Lynx ;) [Though not truly practical for most cases]

It would be nice to see how Iridium fares against WhiteHat aviator https://www.whitehatsec.com/aviator/

I personally find aviator to be more trustworthy at this point though.

foo-bar dear friend.

Lorem ipsum :)

Thanks for the insights. I wonder if a feature by feature in-app purchase on the app would have fared better.

I do not think so. I am not sure if you are aware of Hawala http://en.wikipedia.org/wiki/Hawala or so many other malicious instruments that can be used in a manner similar to crowdfunding. This also includes other factors when looking at international donations to a project which usually come under numerous regulations that need to be answered by PayPal. To not investigate such transactions would be a blunder and the freeze has not been very long. I see no need for an apology for a routine check when it has been clearly stated in their terms and conditions.

Yes. The malicous scripts can already do that. It has taken years to train people and educate them on adding suitable Content-Security Policy headers to prevent such violations without breaking the internet. Every modern technology (especially the XMLHttpRequest) has been more strict on the SOP. However, to introduce a new technology which is more effective than a simple XMLHttpRequest in such a manner that it does not follow SOP when there is no threat of breaking any existing websites is questionable at best.

The Origin header is used to protect the server. This is to prevent the WebSocket Hijacking attack (http://www.christian-schneider.net/CrossSiteWebSocketHijacki...) . i.e. it does not help a lot in the browser end especially in the mashup scenario.

However, the lack of the same-origin policy in WebSockets makes the presence of the same-origin policy in XMLHttpRequests questionable. I am just talking about this part where the browser does not have to restrict a connection to any origin from a given website without even a need for a CORS like whitelist.

Note that this is not an implementation problem but a problem in the general specification of websockets. So there is not going to be a solution to this issue until the specification itself is updated.

I doubt you are the first one ;) .. I was shocked when I discovered this myself.